正方观点：
正规的开发中，应该避免引入第三方组件！
原因：（因为我是反方，所以我也不好描述正方的原因。我有一位老师应该是反方，他的理由大概是，引入第三方组件可能导致质量问题。如果我描述不当，还望这位老师看后补充。）
反方观点：
正规的开发中，不应该避免引入第三方组件！
原因：一般而言，软件开发应该追求利益最大化。第三方组件的引入固然可能增加货币成本（购买组件），可能较难进行质量保证而导致不可控制性（组件内部质量问题）。但同时，引入第三方组件可以明显降低开发成本（这个不用做过多解释了吧），而组件质量问题也可以由开发方和使用方共同努力解决（明确责任，组织测试，制定并观测质量保证措施等）。总之，使用还是不使用，两套方案摆在面前，应该贯彻追求利益最大化的原则进行选择，我们不应该避免引入第三方组件！
BTW：为了解决组件的不可控制性问题，使用方提出必须要得到组件源代码也是不恰当的。质量保证的基线一般不应该制定在源代码级别上，就好比测试不一定全部得做人工走查一样。
请大家参与讨论，至少说出你站在哪方，最好详细说明你的观点！
参与均有分，回复质量好的会多给分。（分不够，最后我可以再开帖子！另请众斑竹支持支持。）
本讨论不局限于B/S构架的应用程序开发，欢迎在（Web开发以外的）各相关版面转贴该贴的URL！
---------------------------------------------------------------
我觉得是看性价比的,没有正反的,看情况而定
可能较难进行质量保证而导致不可控制性:对于楼主所说的问题这不是绝对的,有的话看对你的影响了,如果影响很大话,自然是不用了,比如我同学做手机测试的(跟本题无关联仅仅是举例说明),有时知道哪有问题但无关大局就用狈*^_^*
东西是死的,人是活的
计算的方法涉及很多方面,我突然想起来一件事,楼主现在在学软工,呵呵,我明白怎么有这种问题了
---------------------------------------------------------------
具体到开发的时候还要看你的人员配置,时间要求,功能要求等一系列问题,再综合考虑过后决定如何开发
我记得高程书上有写,呵呵,把自己的观点先写一下
---------------------------------------------------------------
还有看开发的是产品还是项目了
我觉得产品一般来说最好不要有第三方组件,产品是泛性要求的,第三方组件很难达到要求的,而项目是特性要求的,第三方使用的可能性就很大
---------------------------------------------------------------
我认为， 在开发中只要是成熟， 有较高口碑的组件， 是可以放心使用的。
在我看来，基本上认为正规的项目开发中不要使用第三方组件的有两种人（或公司）：
1. 学校里的，没正式开发过项目的。
因为一切基本上都是纸上谈兵， 所以不太清楚项目的成本控制以及其他各方面的实际情况。 所以难免脱离实际。
2. 公司实力超牛，有实力组织内部的高手专门开发相关的组件。
其实即使是这种情况，从成本上来讲一般也是不合算的。因为自己开发组件和别人专门做组件产品的公司一般来讲没法比。 做组件不同于一般的程序， 需要非常严格的编写规范，文档，测试等环节。
而且事实上， 很多功能强大的组件都是国外一些专业的公司集很多优秀工程师的力量， 长期开发积累才得到的。 不可能你想用了， 立刻就开发一套比别人好的。
即使能够达到要求， 很多时候是重复造轮子的过程。除了开发人员的能力有所提升， 公司并没有得到现实的利益， 反而要付出大量的成本。
从软件发展的趋势上来讲， 编程人员就是应该分工越来越明确。 软件的架构也是越来越抽象化，这样才符合软件业发展的趋势。 比如以前我们用 dos, 如果要做一个最简单的，哪怕是扫雷的程序，你都要自己负责绘制界面的菜单，按钮， 图标等，处理鼠标和键盘事件。 非常的麻烦。 windows 出现之后，你可以用 sdk 写程序了， 直接调用 api. 其实 api 已经是很高级的功能了。 你不太可能需要自己去一个象素象素的绘制各种界面元素。 那样太没效率了。 然后各种 win32 平台上的快速开发工具比如 vb, delphi, 都做了更高层次的封装。 发展到 java, .NET, 更加抽象了。 所有的程序指令都通过虚拟机来最终负责调用执行。 从软件的发展上来说， 毫无疑问这是巨大的进步。
最近我开始做一个新项目， 使用 asp.net. 虽然我的 .net 功力尚浅， 在其中我借助了两个非常强大的图表组件， 以及 grid 组件。 在已经完成的部分， 可以看到主页面的代码（手写的部分） 只有区区 40 行左右。 整个程序的逻辑也非常的清晰。
假设使用传统的 ASP + VML + js 来实现同样的效果， 我敢打赌没有几千行代码是不可能作出这个页面的。
关于组件的好处不多说了， 我的废话到此为止 :)
---------------------------------------------------------------
同意反方观点。支持狐狸、小田。
---------------------------------------------------------------
补充说一下，
>>> 假设使用传统的 ASP + VML + js 来实现同样的效果， 我敢打赌没有几千行代码是不可能作出这个页面的。
即使能够实现， 代码要做到清晰，可维护性好， 重用性好，封装彻底肯定非常困难。 难免会有难于理解的嵌套脚本。
---------------------------------------------------------------
狐狸说的.net那种高级封装我倒觉得似乎对算法的要求更高了，从没用过.net，studio.net放在家里没用，呵呵
OOP的东西,MS的过于依赖平台了,高层次的接口需要大家的认可,还有就是效率的考虑,当然用汇编最快,这个就是完全的无组，谁也不会去用的,疯了才用这种无组呢，joke
---------------------------------------------------------------
windows 平台存在着很多的问题。 .net 使用虚拟机机制的重大原因之一就是： 使得应用程序和操作系统底层脱离关系。 微软这么做是有目的的， 当使用 .net 编写程序成为主流之后， 他就可以修改操作系统的底层， 修改一些一直为人所诟病的问题， 比如安全性问题。 而同时他只要修改 .net 平台的相关实现即可。 （以上观点是学习的李维一段录音里面的）
总而言之， 我认为， 不用组件， 或者说 hard coding, 操作底层， 是和强耦合性联系再一起的。 软工里强调的一个基本准则就是，软件要设计成低耦合， 高内聚的。 而控件化，组件化， 虚拟机化正是这一思想的重要体现。
---------------------------------------------------------------
是的，其实道理是类似的。 不过实际的开发中到底是否使用第三方控件或组件（付费的) 要从项目成本和开发周期上权衡考虑。 一般来讲， 组件的购买费用要比开发人员的成本低廉的多， 这一点我想大家不会反对吧？
所以， 认为只要是正规的开发， 就不要使用第三方组件， 这种观点难免有失偏颇。
---------------------------------------------------------------
强耦合,低内聚的观点我是非常赞同的,我自己编程更多的是面向过程
我觉得狐狸的观点跟我一样偏向于中间,是看情况而定的
ps:可以到软工的地盘说说去的,困了,要下了,又一个无效率的一天,我要努力了,为了那个女孩,为我自己,为了我们家的小乌龟,为了许许多多的人们
---------------------------------------------------------------
关注！
---------------------------------------------------------------
我觉得利用一些开源的第三方组件还是可以的，而自己往往希望能过自己的思考和实践去开发出自己的东西来，希望比别人做得更好吧
---------------------------------------------------------------
扬长避短：）
---------------------------------------------------------------
为何总是思想在做怪？好的思想才是根本，至于用什么技术看实际需要吧，没有什么绝对的事情！
---------------------------------------------------------------
对于引入第三方组件的问题我有一些个人看法：
首先，为什么要引入第三方组件？
引入第三方组件不外乎两种原因：
第一、公司没有这方面的开发能力，公司人员现有技术能力无法解决的问题。
此时，则必须要引入第三方组件来解决。不过，这方面还有另外两种解决办法：一是外包给高手完成，二是修改需求和用户协商进行这方面功能的避免。
第二、降低成本！
通过引入第三方组件可以大幅度的降低开发成本，提高开发效率，缩短项目周期，这是必然的，否则，就不如自行开发，也就没有人引入她了。
虽然这样可以解决这个项目当前的问题，但是必然会带来负面效应，下面同样按照上述两种方式进行分述：
第一种方式的采用分为两种情况：
外聘高手或者外包给高手开发虽然给公司解决了当前问题，但是无法解决项目后续的升级开发问题，如果根据需要对这些组件进行二次开发，同样还需要外包给这些高手来继续完成，这对于公司来说，是一种束缚，如果双方合作愉快，则事情必然很好解决，如果有一方希望能够获得更大的利益而对另一方施压，则结果是很明显的，必然会引起双方合作的不愉快，或者带来其他不方便的事情（目前国内手机行业就面临着类似的问题）。
而采用变更的方式避免这个技术问题的话，这个问题只是被延后了，而不是被彻底解决了。用户到了项目的中后期仍然可能提出同类的问题，或者在第二个版本上提出同样的问题要求解决。这个时候，仍然会面对上述情况。
第二种方式的采用也将分为两种情况：
第一种是采用了可靠的有持续升级和服务的第三方组件，如果这个组件的提供者属于某一个民间组织或者个人，其状况将类似于第一种方式的第一种情况。
第二种是不付费的采用了免费的第三方组件，这个时候，项目组面临的问题将是在升级或者新版本的开发中面临与第一种情况的第二种方式相类似的现象，但是，这个时候用户提出的问题往往会高于前一阶段的要求，也就是说需要在这个免费的第三方组件上进行二次开发。此时，就需要研究这个第三方组件的