也谈对组件化软件开发的几点看法，欢迎大家发表自己的见解

最近看到网上很多关于基于组件或者控件开发的讨论。我想谈谈自己的想法仅供大家参考：
首先应该说纯软件开发而言过去的典型模式就是垂直型的，这类模式就是开发队伍全权负责某个软件各个功能的实现。他们负责某个软件的功能设计、代码编写、测试安装，另外也负责软件内各个模块的功能划分以及接口定义。这是传统开发的主流模式，其实也是之前唯一可行的模式，因为如果想要把一个完整软件拆散分配给不同团队协作必然涉及到将来各个模块如何组装在一起的问题。这就需要一套比较完整的体系框架和接口做保证。上个世纪末期虽然有了一些简单的体系框架和重用标准如DDE,OLE等但是其稳定性、体系的完备性等方面都差强人意，勉强粘合在一起的各个第三方组件其稳定性让人失望。所以干脆自己动手解决所有的问题是当时自然和合理的选择。可是现在的情况已经大为改善了。微软的组件标准由最初的OLE到COM， DCOM， COM+直到最近的.Net体系羽翼渐渐丰满，而其它的组件标准如CORBA也日益成熟，Java系列标准如Java Beans/EJB/RMI等也都逐渐丰富起来，可以说目前主流开发平台已经逐渐向组件化方面发展。和C语言时代不同了，现在的主流开发语言不能提供一套完整的组件开发接口就无法在今后的竞争中有立身之地。CORBA标准我不太熟可是看看.Net Framework平台体系底层固化在平台上的功能越来越少，真正的也就是一个CLR，剩下的都是自底向上累积起来的各种类库，整个体系完完全全的对象化，也完完全全的组件化了。无论是其实现的基本IO还是更高级的诸如数据库存取都用其上的各种封装类库，外来第三方类库可以非常方便的集成到.Net Framework体系中，和微软自己编写的类库唯一的区别也就是Assembly Name不同了。这种搭积木的方式为过去的封闭式开发平稳过渡到分工组件化提供了客观的条件。所以组件化的开发方式是今后的趋势，这是水到渠成的事情了。
第二点，过去谈到软件封装、组件化之类往往都是在软件重用（Reuse）的范畴之内讨论问题，提起软件重用往往有一种废物利用、厉行节约的味道，而且也基本上都是一个组织、单位内部的事情。最典型的场景就是某个企业的软件开发人员或者主管开发很多项目之后往往颇有感慨的总结：这么多项目，很多功能模块都是重复开发，浪费了大量人力物力，如果类似功能的代码能够重用就好了。。。我的观点是能够重用当然好，但是在一个企业内部这种重用意义不大，因为单个企业内部能够涉及的项目还是有限的，能够把某类功能提炼为成熟稳定的组件化产品的实践经验还太少，即使真正费了很大力气把普通项目中可以重用的部分识别出来并且单独加以封装，能够用到今后项目中的机会也有限，和能够得到的好处比起来其前期所需要的重用模块识别、接口定制等成本太大，往往最后导致愿望很好、实现起来很困难。所以现在软件组件化的意义更重要的是产业分工。一个软件的开发包括哪些必须的步骤，我的理解就两大环节：一个是设计、一个是实现。设计是确定系统要干什么，实现就是设计目标的代码化。这两个环节体现了两种不同的能力，确定目标设计系统主要是对目标客户行业流程的理解和把握，代码实现主要是对软件语言语法的理解。大家平时经常提到企业的核心竞争力，对于纯开发技术方面目前的趋势是开发工具(IDE)已经慢慢演化为标准化运行平台，它仅仅提供最最基本的核心功能，更为重要的是它们都定义了一套体系完善组件接口，更高层面的功能就完全有赖于各个第三方组件对其丰富和拓展了，某种意义上而言它们已经演化为一个新的操作系统。基于这种背景开发平台标准事实上已经垄断在少数几个大的软件寡头手中。所以我们的重心应该转移到对领域客户业务的把握与系统设计上，因为软件和其它任何一个行业都有一个共同点就是产业化的分工越来越细。既然我们的软件企业在整个产业链中更加靠近最终客户我们就应该好好利用这个资源，把自己的目标行业做深做透形成自己独特的优势。也许对技术起家的软件企业而言会觉得研究各种底层技术才是本分，整天和客户讨论各种流程需求多多少少有些没落，其实这只不过是技术人员的传统思想作怪，有道是行行出状元，不要忘了现在第一大咨询公司埃森哲就是专门研究不同行业的业务流程以及IT项目顾问为主的，虽然不涉及任何具体的技术编码可是同样让国内任何一家IT公司难望其项背。IT行业的老大IBM也越来越把产业咨询顾问作为其业务中心。同样是企业级软件市场的老大SAP其产品的核心竞争力方面还是其ERP产品反映出对行业领域流程的准确把握上，至于其开发产品所用的技术和语言可能甚至比不上国内很多公司那么摩登时髦。所以国内软件企业利用组件简化自己的开发负担而更加着力于业务分析和设计是更好的选择，软件开发今后就像建筑产业，实现各种模块功能的组件、代码将会变得如同水泥砖瓦一样既普普通通又垂手可得，也正象建筑领域一样最有价值的公司是那些懂得设计、成本及质量控制的企业，没有哪个房地产公司会因为自己拥有某种特别好的水泥或者空心砖而自鸣得意。虽然软件开发不象盖房子那么没有技术含量可是开发技术平民化、大众化也是大势所趋了。昔日那种懂得某个特殊的技术一招鲜吃遍天的日子现在已经很少了；
第三点，有关目前软件组件产业群的分析。其实采用组件化开发在国外已经非常普遍了，目前全球已经有超过110家软件企业生产超过上千个不同种类的软件组件，其中相当一部分组件有源代码可以选购，而且和普通软件不同组件产品一般来说是作为开发工具而销售的，用它们开发的产品其成本软件商仅仅需要支付一套产品的价钱，而不管你利用该组件开发的最终产品卖给多少客户，收取多少License的费用。根据初步统计软件行业的各大公司都广泛采用组件来开发产品，甚至世界五百强中绝大部分在自己的项目中也多多少少都采用了不同的组件产品。所以组件化开发的需要的‘弹药‘现在已经很充足了，而且很多组件商都是在各自领域经营了数年甚至十几年，其所生产的组件产品无论是从质量还是性能方面都达到商业化水准。很多大家所熟知的软件产品都为商家带来滚滚财源，可是很少有人知道许多这种摇钱树产品其核心模块却是仅仅花了几百美元从组件厂商买来的。因为组件产品是半成品，它们往往被最终产品包装起来而自己充当幕后英雄不为人知。从某种意义上讲种类繁多的组件产品对国内的软件公司来说就像一个待开发的金矿，善于利用现有的组件，挖掘它们潜在价值，也许几千块钱的投入会衍生出一个数亿元利润的产品。这种积木式的新产品开发模式要比为了实现某个复杂的核心功能而殚精竭虑的封闭式模式好多了。
最后一点，想谈谈如何利用组件开发软件的问题。一般来说组件分为免费以及商业化的产品，同时也有带不带源码的区别。总的来说免费的组件功能往往比较简单，产品的性能、稳定性以及后续升级完善方面没什么保证，原因很简单本来就不收钱的东西别人没必要对你保证什么。商品化的组件在上述方面要好多了，而且都有完备的文档以及后续服务。对于什么场合、项目应该词采用组件我大致归纳了一些情况：
1。软件企业具有一定规模，打算长期在某个领域推出通用性的产品 -- 建议购买跟产品核心功能相关的带源码商品化组件，因为一次投资后随着自己产品的后续升级完善以及类似产品线的扩大可以长期重复利用所购组件，并且如果有源代码可以根据自己的需要修改完善其功能从而不断升级自己产品，也就是通过购买高质量的核心功能组件来打造自己在目标领域的产品优势，这类情况考虑的是组件的功能和扩展性为先，产品价格其次；
2。软件企业具有一定规模，所做项目大多为一次性定做项目 -- 可以考虑购买不带源码的商品化组件并结合免费组件。因为这类项目彼此间通用性比较少，也许为了一个项目而购买的组件其功能在其它项目用上的机会很少，那就没必要花额外的钱去购买组件的源代码了。另外有些功能能用编费组件源码就尽量用。因为不需要考虑太多的后续升级和拓展，独立的项目更看重的是成本，组件的质量Good enough就可以了；
3。软件还处在初期阶段，打算在某一领域确定优势，推出通用的产品。这种情况的企业我觉得可以从两个方面考虑自己的选择，一种是选择一个自己业务很熟悉的领域，通过系统设计和功能取得产品竞争优势；对于很多初期阶段并没有自己优势领域的企业我觉得倒是可以先在组件市场上找找，看看有什么产品比较新颖、自己可以用来简单包装就迅速推出产品的。毕竟在这个技术日新月异的IT领域产品推出的速度决定了一切。你有再好的想法、再高的目标做出的产品比别人哪怕晚半年基本也没什么意义了。这里我特意提到了商品化组件，因为第一它质量稳定后续服务可靠，便于在此基础上长期经营相关产品，如果是免费组件基本上都有很多Bug，引进修改消化就要很长时间，而且因为是免费的谁都可以轻易拿到，所以在此基础上模仿衍生出的产品比较多，那么你的产品就很难一下子确立在技术上的优势。
4。最后一类就是企业刚刚起步，还处在靠订单维持基本开销的企业，我觉得这类企业可以关注市场上某些类感兴趣组件的情况，不过除非下决心推出长远计划的产品否则不要轻易出手，因为购买组件的成本是小，关键是能够短时间内支撑开发通用产品需要的人力物力。
以上是本人对组件化软件开发的一点看法。不很成熟多少也算一些体会，欢迎广大同仁多谈自己的想法。毕竟组件化开发相对来说还是个新的事务，我们的软件行业需要对它有更多的研究与了解。
==========================================
摘自中国组件网论坛( www.componentchina.com)。
中国组件网---权威组件及源代码经销商