1. 软件复用是提升项目交付效能的关键因素

1.1 什么是软件复用

软件复用(Software Reuse)是指将已有软件的各种有关知识用于建立新的软件，以缩减软件开发和维护的花费，是提高软件生产力和质量的一种重要技术。

软件复用对程序员来说是再平常不过的事情，可能从学校里的编程作业开始，我们就在接触复用。早期的软件复用主要是代码级复用，被复用的知识专指程序。但其实领域知识、架构设计、技术文档等知识类的沉淀，同样适用上述定义，也属于软件复用的范畴。

按不同级别划分，软件复用通常有以下形式：

1. 代码Copy：最简单直接的方式，也最常见

2. 组件复用：在一个应用工程内，通过利用已有的组件去实现部分功能。比如在阿里广泛使用的fastjson，比如Spring Cloud工程脚手架。

3. 应用复用：比组件复用更进一步，通过API方式去使用已有的服务，比如提供发短信能力的一个微服务。这个服务对消费方来说是一个黑盒，不需要对这个服务的源代码做修改。

4. 产品级复用：这里是指能够开箱即用，仅通过配置就能适配客户的个性化需求。通常是指SaaS类的产品，意味着很高的场景抽象能力，同时也和业务场景和定位有关。

复用级别上升，复用的效率也会上升，但同时适配不同客户场景的灵活度却会下降，有点像机器学习算法里的过拟合。所以并不是一味地追求高级别的复用就好，下文会重点阐述。

1.3 交付项目中软件复用的特点

在项目交付的语境下谈复用，本质就是为了提升交付的效率，加快项目从客户的想法到实际交付到客户手里的时间，并减少投入的人力的资源成本。在项目交付中，最关键的约束就是成本和时间，如果脱离这两个因素，软件复用也许不那么紧要。但对我们做项目交付的而言，这两点恰恰是最敏感的。

另外，在云计算时代，开发者是交付场景下，软件复用的主要对象（贡献&消费）。云产品很强大，但大部分是PaaS产品，还需要技术加工，才能满足客户的具体业务需求。通常开发者会深耕在一个行业里面，不断积累交付经验，并有机会进行沉淀。这里的沉淀，就是软件复用的源头。

在这样的背景下，软件复用就需要考虑开发者的特点，包括不同组织之间如何进行技术资产的互相流通；包括软件是否有足够的说明文档、演示Demo和技术支持来帮助技术水平较弱的开发者也能合理地进行复用。

2. 软件复用的难点

软件复用是提升交付效率的核心手段之一，但要实施起来却也有很多困难，主要在于以下三点。

2.1 “非我所创”综合征

“Not invented Here Syndrome”，指的是社会、公司和组织中的一种文化现象，人们对不是自己所创作的软件存在一种天生非理性的排拆感。

所谓程序员重复造轮子的现象，也有这方面因素的影响。要拒绝复用，总是能找到理由，比如批评某个开源项目的API设计不够优雅等等。其实回想一下，过去我也有这种心态，有时候就有冲动按自己的想法去实现一遍。

对于核心业务模块，强调把控力而选择自建，也许无可厚非。而在强调时间和成本的场景下，复用显然来得更为重要。

2.2 软件复杂度影响复用

技术架构能过简化软件的复杂度，但再好的架构设计，它在刚完成时是“清白”的，随着实施的进行，它的复杂度也随着功能的增多而逐步累加。

实际上，如果通过代码Copy的方式去移植整个系统，也就意味这复制原系统所有的复杂度。在原有为A客户的场景所开发的代码上，去做修改，实现B客户似是而非的需求，所付出的开发和测试的代价，会让软件复用的收益大打折扣。

相对代码copy这种方式，如果对软件进行足够的模块化设计，每个模块按照高内聚、低耦合的规则去设计，仅实现原子化的功能。模块可以是组件、或者服务的形式，对外提供SDK或API。那么在软件复用的时候，就可以仅仅复用这些模块，而舍弃原来项目中用于粘合各个模块的业务代码（通常集中了客户定制化的需求，对应整洁架构中所谓的防腐层）

当然，这些模块对调用方来说是黑盒的，所以组件的设计和与内部实现开放程度会决定软件复用的程度。

2.3 获得技术支持难

如果是开源软件，当我们开源它的源代码，供人复用的时候，不会强制提供技术支持SLA。这也是为什么很多开源软件除了有社区版，还有对应的企业版，它的核心在于提供专业的技术支持。

所以在决定是否要复用软件资产的时候，除了软件本身的功能和质量，是否能获得技术支持也是决定性因素。对开源软件而言，就是看它是否在持续更新，社区是否活跃。

3. 适合交付项目的软件复用形式

建筑设计 vs 土木工程

有些业务场景，可以通过SaaS化的软件，来实现“拎包入住”。但阿里云总集的大型项目，它的特点都是客户的场景并不那么“标准”，或者说本质上就是在做数字化转型的探索，需求的边界比较模糊。

此时的项目交付，其实非常像造大楼。首先，需要技术架构师绘制蓝图，关注宏观的架构设计，并和客户确认。架构设计决定了这个建筑的上限，能否成为地标性建筑（所谓的地标，就是与众不同，无法整体照搬）。

然后到了落地实施环节，软件复用就像土木工程，关注实施的细节过程。软件复用好比搬运和安置土木砖块。它决定了这座大楼能不能如期建成，以及建成之后能矗立多久。

模块化的软件复用

理想的软件复用，和打造火神山、雷神山医院有异曲同工之妙，在工厂里做好预置的模块，运输到工地现场，组装起来，通过这种方式去大大缩短工期。

软件复用的颗粒度越大（对应之前说的复用层次越高），它的复杂度就越高，需要现场去适配和调整的代价就越大。甚至可能需要用户来削足适履。而独立模块，功能上越内聚，并且对外部依赖越小，它才越容易被复用起来。

所以适合交付场景的复用，就是做好模块化拆分，以是组件、或者服务的形式去打造预制件。就像乐高积木一样，颗粒度尽可能小，才能方便地被插拔到各个地方并重新组合。至于怎么根据客户定制化的需求，通过“胶水”代码去调用组件，进行装配的工作留给交付现场。

4. 建设资产市场，提升软件复用度

4.1 建设资产市场

前面提到，客户的个性化需求是复杂而多变的，大多数情况下，开箱即用的产品并不能满足。比较而言，完成特定功能，供交付项目按需取用的预制件要来得更适合。

知道要建设什么样的资产，我们还需要一个在线的资产市场来承载它们。能对资产做集中管理，并供潜在的用户浏览和发现。

举个例子，我们都知道应用的安全性重要，但在项目交付中，有时候又是比较容易忽视的，防范不到位。这个时候，如果有一个好的通用安全组件，并提供给开发者去使用，帮助大部分的项目把安全防范提升到一个及格的水位。

4. 总结

在交付场景下，客户的定制化需求非常多。没有两个项目的客户需求是完全一样的，很难通过单纯的产品复用来解决客户需求，定制开发是必不可少的。在这里，我们关注的是土木工程，通过高质量的预制件来提升交付的效率。通过构建一个在线的资产市场，使得资产的标准能够得到统一，并且是通过一个开源社区的运作模式，伙伴的开发者也被引入进来一起共建。