软件复用是个技术活

系统复用为什么难？

还是从事例说起，我们做医疗行业的应用系统，健康档案的管理是一个非常普遍的功能，我们在某系统里已经开发了稍微完整点的模块，于是乎只要其他应用要开发健康档案的功能，老板就会说这个我们都做过了，拿过来用就好了，为什么要重新开发？我来尝试的回答下这个为什么很难复用。

1、这个系统由于历史原因，是.net开发，而我们团队主流的技术栈是Java，开发语言都不一样，没法复用，只能参考。

2、虽然都叫健康管理，但是不同的应用系统，他们的差异化还是非常大，慢病管理和专病管理有差异，在基层医疗和等级医疗有差异，即使同构系统，其实也无法直接复用，需要二次改造。

3、如果这个模块不是以公共组件的方式进行抽象设计的话，它其实和当前系统是紧密耦合的，数据层的耦合，业务逻辑层的耦合，视图层的耦合，特别是代码级的耦合，如果在其他系统复用，首先要去除这种耦合然后在做适应化改造，复用的成本有时候不比重新开发低。

1、复用是有成本的

DRY原则（Don't Repeat Yourself）相信每一位程序员都应该知道。其指代的是我们写程序时，不要一遍又一遍地编写相似的代码。当出现某些相似功能的代码时，我们应该将通用部分代码与特异部分代码分离，以达到复用通用代码，降低整体复杂度的目的。

复用这个道理我们都懂，我们也在实际的开发过程中真正去践行的，但复用其实是有成本的，这也是为什么我们知道重复制造轮子不好，但却又不停的的在制造轮子，因为很多时候造一个新轮子比改造一个轮子可能更快，成本更低。

复用有哪些成本呢？

1）发现可复用组件的成本

很多时候我们并不是不想复用，而是不知道是不是存在我们需要的轮子，从哪里可以找到这个轮子，正如本文最开始的那位研发负责人，他可能真的不清楚哪个团队有他可复用的轮子，而老板看到的范围更广，所以她更清楚。这个和组织管理和知识管理有关。

2）学习可复用组件的成本

别人造的轮子有时候很难了解它内部的构造和逻辑，就要去学习别人造轮子的设计和逻辑，这个本身是存在学习成本的，如果对方的设计和实现与自己的思路存在出入的时候，又会非常的别扭。

3）扩展可复用组件的成本

前人造的轮子都是用在他当时的那个场景或者业务中，当这个轮子切换到新的场景和业务中的时候，你会发现100%的可复用基本上是没有的，这时候就牵扯到对于这个轮子的扩展以适用新的业务，先不说这个扩展改造是所有者执行还是使用者执行（后面有一个章节专门讨论组织的逻辑），扩展总是有成本。

4）修改可复用组件的成本

有时候组件的抽象能力不够，无法扩展，或者扩展的时间成本太高，或者组件所有者不愿意支持，复用者可能采用直接拿过来修改的情况。修改的成本是一个层面，但把时间拉长来看，组件修改后就和原组件分化了，未来双方的新功能也无法相互复用了。

2、复用是有级别的

一般情况，复用的成本会因为复用的组件的内容不同，所在组织的关系亲密，它的成本是不一样的。比如只是复用一段程序，就相当简单，如果复用一个系统功能就很困难；如果复用同一个团队的组件就相当简单，如果跨团队跨组织的复用就会变得困难，所以复用也是有级别的，为了更好的理解我把复用分成了一下5个级别。

级别越低，粒度越小，复用的范围越广，但价值体现较低；级别越高，粒度越大，复用的价值越高，但复用范围也比较局限。所以站在业务和价值角度上，都是先从最高的层次上去复用。只有上层无法实现复用，我们才会逐步向下层去寻找。但是有时候站在技术角度，我们习惯在低层次上去复用，因为这里最接近自己的工作，粒度越小，技术上越可控。

 

回到本节开始的问题，B系统的功能要复用A系统的功能，这个复用级别是最高的，如果能复用那会极大减少工作量降低成本，但这个级别的复用难度也是最大的，特别是异构系统，就几乎没有可能了。

       今天各种PaaS很多都是为了解决软件功能复用问题，尤其是各种技术中台，但框架级的复用其实属于最容易复用且成本最低见效最快复用方式，也就是属于一级复用，例如Spring框架，公司、团队切不可犯技术不统一的毛病，技术生态不统一意味着，公司要花更多的成本养活不同领域的开发者，学习、维护等成本居高不下，切不可犯的低级错误！挣钱不容易，切不可乱花！