中台|啥都复用不了，还谈什么狗屁中台

编辑导读：说到中台，很多企业尽管都在搭建，但是对它的了解不够深。比如一套系统，为什么不能复用？复用需要一个体系的设计，一个组织的支撑，一个相互信任的团队文化，一个不断完善的过程。本文作者从自身工作经历出发，对此进行了分析，一起来看看吧。

最近一个项目汇报的时候，我下面的一个研发负责人被老板“骂”了一顿，原因是老板认为这个功能之前某某项目，某某系统做过了，为啥要重新开发，拿来用就行，结果这位研发负责人讲不清楚，或者技术人员太实在而不知道该如何表达，最后也把我叫过去数落一番。
我不怪老板，她的想法是可以理解的，站在投入和产品角度，不要重复制造轮子是没有错的；我也不能完全怨我的下属，有些东西的复用和集成的确是不像做PPT那样东拼西凑那样容易的。
双方都没错，那问题出在哪呢？我将这个问题发到老谭的读友群里，大家讨论的也挺热烈，看来这个问题的确也是大家普遍存在的问题。
有人吐槽老板不懂技术，需要上课的；有人建议需要沟通，需要不断磨他，盘他的；还有人还建议让老板参与几个典型项目，让他多体会体会的；最后我们把问题归结到“信任”二字，原来所有的问题都可以通过“信任”来解决的。
的确信任可以解决任何问题，老板如果一点不懂，他可以信任他的CTO能很好的解决这个事情；如果老板很懂，他就会亲自解决这个问题了。今天我们不讨论老板的问题，他的需求本身没有问题，如果我是老板我也会要求不做重复投入。本文我更多要站在技术领导者的视角去尝试解析这个问题，寻求一定的解决方案。
一、系统复用为什么难？还是从事例说起，我们做医疗行业的应用系统，健康档案的管理是一个非常普遍的功能，我们在某系统里已经开发了稍微完整点的模块，于是乎只要其他应用要开发健康档案的功能，老板就会说这个我们都做过了，拿过来用就好了，为什么要重新开发？我来尝试的回答下这个为什么很难复用。

这个系统由于历史原因，是.net开发，而我们团队主流的技术栈是Java，开发语言都不一样，没法复用，只能参考。
虽然都叫健康管理，但是不同的应用系统，他们的差异化还是非常大，慢病管理和专病管理有差异，在基层医疗和等级医疗有差异，即使同构系统，其实也无法直接复用，需要二次改造。
如果这个模块不是以公共组件的方式进行抽象设计的话，它其实和当前系统是紧密耦合的，数据层的耦合，业务逻辑层的耦合，视图层的耦合，特别是代码级的耦合，如果在其他系统复用，首先要去除这种耦合然后在做适应化改造，复用的成本有时候不比重新开发低。

1. 复用是有成本的DRY原则（Don’t Repeat Yourself）相信每一位程序员都应该知道。其指代的是我们写程序时，不要一遍又一遍地编写相似的代码。当出现某些相似功能的代码时，我们应该将通用部分代码与特异部分代码分离，以达到复用通用代码，降低整体复杂度的目的。
复用这个道理我们都懂，我们也在实际的开发过程中真正去践行的，但复用其实是有成本的，这也是为什么我们知道重复制造轮子不好，但却又不停的的在制造轮子，因为很多时候造一个新轮子比改造一个轮子可能更快，成本更低。
复用有哪些成本呢？
发现可复用组件的成本！
很多时候我们并不是不想复用，而是不知道是不是存在我们需要的轮子，从哪里可以找到这个轮子，正如本文最开始的那位研发负责人，他可能真的不清楚哪个团队有他可复用的轮子，而老板看到的范围更广，所以她更清楚。这个和组织管理和知识管理有关。