从有编程开始，软件复用就是一个很吸引人的话题：开发一个软件模块，然后不断在其他程序中使用，没有成本，没有Bug，投资一次，收获无数，真是天大的好事。第一次给软件复用披上方法论的外衣是1974年Steven，Myers，Constantine在IBM System Journal上发表的里程碑文章“CMMI结构化设计”，他们提出有效支持复用是结构化设计的主要目的之一。

      复用考虑也是CMMI认证实践域的主导因素之一，可惜太多的IT组织、团队没有真正理解软件复用，他们的理解还是局限于工业设计中的部件复用，可程序的联调编译和构建一个房子，组装一辆车不是一码事。所以CMMI咨询认证是软件开发过程中的软件复用是我每次评估时关注的一个重点，实际现状是雷声大雨点小。不少组织的做法是建立维护一个组件库，从完成的项目中收集一些可能会被用到的模块，同时要求新项目的开发人员在编码前在库中寻找可用的东西。    如果组件库内容稀少，程序员找不到可用的东西，几次下来不会再来光顾了。如果库中内容丰富，查询变得困难。复用模块大也不是，小也不是。太小，搜寻和模块定制的投入恐怕比重写花的时间还多，实在不值。如果模块太大，不光搞清楚其中细节要花一番功夫，是否和新开发的应用完全一致也不能保证，至于模块用的测试环境和其可靠性估计也很难确定。模块提供的质量属性往往不会和新应用场景匹配，而架构的不匹配则是更大的问题，新应用的架构很可能和复用模块开发依附的架构不同，导致接口处理成了一盆浆糊。最终结果是我常听到的，“复用，我们努力尝试了，但做不到”。    软件复用之路应该怎么走？应该从哪里入手？软件架构大师Grady Booch指出“根据我的经验，将软件开发重点放在所谓“重用”上是一种误导。应专注于重构文化：这不仅会产生越来越简单的高质量的软件，而且随着时间的推移，重用将以模式和框架的形式出现”。也就是说，软件复用之匙在设计模式（架构）在框架。成熟的架构和框架为开发团队提供了一套经过验证的工程模式，开发人员可以用它来解决具体应用问题。

     “设计模式”（design pattern）是一本我指定给软件工程研究生的必读书，这本书不大好啃，四位作者梳理出了3类（creational，structural，behavioral）23个模式（patterns），给出了各自的应用场景。书中不仅指出了软件复用设计必须考虑的问题，也告诉我们那些模式（patterns）可以帮助我们解决这些问题。记得当年在硅谷有个说法，如果你能熟练应用其中8个以上模式，你绝对是个牛逼的软件架构师。

架构复用为类似需求系统的实现提供了强大支持，把复用提升到一个更高的境界：不仅相关代码可以复用，形成架构的需求、相关的经验、支持体系也可以复用。    记得多年前，在帮助一家银行IT规划软件复用改进专题时，针对其有数百个产品的现状，我提出了建立软件产品线的思路。因为仔细分析后，我们发现许多产品的共性点远大于差异点，这让在类似产品实现架构复用变得可能。    一个软件产品线是一个软件系统家族，它们是由同一组可复用资产开发出来的。其中最重要的资产是可以支持整个家族的软件架构，架构规定了所有家族成员固定的内容以及可变的内容，是最重要的技术投资。    软件产品线通过建立明确严格的场景以支持有效复用：明确定义的架构，支持的功能，透明的质量属性，以及其他基于公共架构的软件元素。产品线新成员的开发复用包括需求、架构设计、软件要素（如接口、设计等）、建模及分析、测试资产、项目管理资产、过程/方法/工具、团队、典型系统、缺陷清除等。这些复用让高质量产品开发变得短、平、快，在快鱼吃慢鱼的世界，是企业在竞争中取胜的重要法宝。    产品线建设需要前期大量投入，也需要日常的维护，众多IT组织（包括中国的华为、银行、军工）的成功经验证明产品线是让软件复用助力企业快速发展的有效手段。产品线也让软件架构师有了更好的用武之地。    多年后在为这家银行软件中心做CMMI复评时，很欣慰的在评估文档里看到了产品线维护优化的材料。快速IT响应是众多软件组织追求的目标，复用是自然的选择之一，复用之路没有捷径，需要我们坚持不懈的学习、实践、创新。

来源于丛斌博士