软件复用

  快速软件开发的核心是“复用”，“复用”可以出现在软件开发的各个阶段上，如分析、设计、代码等，复用也可以出现在不同的层次上，如库（组件）复用、框架复用、产生式复用等，在特定领域可以获得更高的复用性，在横向可以实现业务模块的复用，在纵向可以把领域经验抽象为底层的软件基础设施。

  复用是什么？我认为复用（代码层面）是用更少的代码解决更多的问题，更少的代码的基础是重复利用原来的库、组件、框架、业务模块等已有的相关技术积累，由于代码层面的复用更底层、往往也包含着分析和设计等上层复用，如用几行代码调用一个已有成熟的业务模块，那么该复用就包含了这个业务模块的分析和设计。

  库（组件）复用是非常底层也非常高效的复用方式，如JAVA和.NET提供了大量的类库，大大提高了开发者的开发效率。开源社区提供了更细分、更专业的库包，如Apache Commons。很多公司也会开发出自己的库包（组件），这些库包往往更专注于公司所在的业务领域以形成自己的技术积累；但做到这一地步在中小企业里并不多见。

  框架复用也是最常用的复用方式，在JAVA社群里，SSH(Spring + Struts +Hibernate) 几乎成为开发者必备之“武器”，SSH提供了UI界面、对象管理、数据库持久化等较完整的开发框架。很多公司在SSH基础上加入自己的库包或加上开源工作流的支持，便形成自己的“平台”，这是非常经济的做法，利用成熟技术快速搭建自己的平台。但是，SSH也并不是那么容易被掌握的，很多公司有滥用开源框架的趋势，不停得在”平台”中加入其它的开源项目， 最后已经无法掌控自己的平台。

  产生式复用是通过一个代码生成器，根据一定的规则产生代码（正向工程），以减少程序员的重复劳动。产生式复用和框架复用很多情况下结合使用，如生成SSH需要的相关类、注解或配置，大多数公司内部提供的“平台”都会提供产生代码的功能。产生式复用远远没有宣称得那么威力大，因为大部分“平台”只提供正向工程，即仅仅提供技术层面的一次性代码生成工作，是静态、而不是动态基于业务逻辑的交互生成。 有些商业性质的“平台”会提供正向工程和逆向工程，但是对代码的侵入严重，封闭而呆板的体系结构造成了“简单的事情更简单、复杂的事情更复杂的”现象。  MDA（模型驱动架构）提出了一个更高的复用目标，根据上层的平台无关模型可以生成不同语言平台的代码，但是现在还没有特别成功的案例。
无论是库复用、框架复用、还是产生式复用都是偏重于技术底层的、和代码相关的复用方式。一旦需要变更，必然会重新编译、重新组织代码、甚至复用失效重写代码。

  业务模块复用是基于相关业务领域的软件模块复用，很多产品型公司进行产品实施的过程，往往也是复用业务模块的过程，我们可以看到一个现象，很多项目的实施周期非常长，很多模块都需要重写，业务模块很难被良好得复用。一些大型的公司往往投巨资打造”软件平台”，在非常专业的领域，比如中小企业财务，可以把各个方面考虑得比较周全，但是一旦离开其专注的领域，例如进入集团财务、银行财务，原来的业务模块基本上需要重写。
我们看到，越高层次的“复用方式”越难以“复用”。业务模块复用是建立在上述库（组件）复用、框架复用、产生式复用之上的，由于其层次更高，上述复用方式带来的问题会加倍放大。不同公司、不同项目的“业务”之间即使业务相近，但完全重用原来的“业务模块”是不可能的，不同公司、不同项目的“业务”必然有自身的特点。一般“业务模块”会参数化，即可以根据参数的配置来个性化“业务模块”的表现行为，但是参数化的数目是一定的，而业务的差异是不可穷尽的，如果业务差异化太大，复用人员往往产生干脆重写一遍的想法，其实很多公司确实是再重写一遍；还有一些强势的乙方会牺牲客户的使用习惯来强制达到“复用”的目的。

  如果“业务模块”本身不是二进制的，即“业务模块”不是具体形状的“积木”，而是可以随意改变形状的“变形金刚”，那么高层次的“软件复用”问题会迎刃而解。“变形金刚”式业务模块不可能建立在二进制代码至上，一般是建立在领域经验抽象出来的“软件基础设施”之上。

  “变形金刚”式软件复用也是基于特定领域的，但是它比用穷举法解决问题的领域要大的多，并且实现的成本也低的多。“变形金刚”式软件复用的基础是对所在领域的高度抽象，不是在代码层面，而是在领域层面解决问题。“变形金刚”式软件复用的一个重要实现就是DSL，所谓领域专用语言，可以用非常少而精炼的代码解决问题。DSL或类似DSL的解决方案在某些领域取得了巨大的成功，如SQL语言，Ruby ROR，Salesforce Force平台。  所以，我们需要的不是“积木”式软件复用，而是“变形金刚”式可灵活调整的软件复用。