你真的懂软件复用吗？

免责声明~

任何文章不要过度深思！

万事万物都经不起审视，因为世上没有同样的成长环境，也没有同样的认知水平，更「没有适用于所有人的解决方案」；

不要急着评判文章列出的观点，只需代入其中，适度审视一番自己即可，能「跳脱出来从外人的角度看看现在的自己处在什么样的阶段」才不为俗人。

怎么想、怎么做，全在乎自己「不断实践中寻找适合自己的大道」

1 前言

重用和复用，似乎是一回事，但似乎又有区别。如果是一回事，那么在软件架构设计中，复用主要体现在哪方面？

系统设计过程中，经常听到「复用」，以「复用」为目的来设计技术，业务，组织架构。如：

• 抽象出一个类，函数，UI 组件，用于不同场景
• 抽象出一个微服务，越细越好，这样可以灵活的组合
• 抽象出一个业务中台，沉淀各种基础业务功能，供全公司使用
• 组织（管理）架构中，抽象出一个职能竖井（后端，前端，QA，财务），被不同的产品使用
• 产品设计中要完成一个性能功能，发现跟之前一个功能相似，就复用之前的功能设计，改改继续用

2 为什么我们喜欢复用？

• 主要目的：既然一部分功能已经存在，为什么还要自己造呢? 直接拿来用，这样我可以做得更少，所以能够提升个人的生产效率
• 接受的教育：大部分工程师都学习过 DRY principle; 《设计模式》的的英文书名就是《可复用面向对象软件的基础》，都强调复用
• 编程习惯：OOP习惯继承，而继承对于大部分人来说就是为了复用

3 复用就能提高效率的逻辑

• 如果我们要写一个系统的所有代码，我们需要写大量的代码
• 如果我们能从其他地方重用一些以前写过的代码，就能写更少代码
• 重用的代码越多，写的代码越少
• 写的代码越少，就会越早完成系统

4 逻辑误区

• 所有的代码（功能）需要相同的时间来写
• 写代码是完成系统的最主要工作

如果你要写得代码依赖很多其他的复用模块，你就要去理解不同的复用模块提供的接口，很多时候只看文档不行，如果复用模块的接口不是正好适用你的场景，你就必须在讲究使用接口和对方排期之间选择。对如何抽象出一个公共业务模块，大部分人都没标准，公共业务模块的负责人成了业务外包，效率更低。

任何维护生产环境系统的人都知道写代码只是整个工作中一小步，而且是确定性最高的一步，之后维护最占用时间。我们需要不断调试，部署，再调试，部署。一个用于很多依赖的模块相对依赖少的模块做这些工作的难度是高很多的。

5 复用这么多问题，那各种框架/库都自己重写？

肯定不需要啊，我们平时会使用各种编程语言 (Java，Go) ，框架，库。用这些没任何问题，因为他们够通用，一般化，并不是为了某业务或公司定制。先有[共识，标准]，再谈复用，而不是随意拿来用。

6 那我设计系统时，尽量设计通用化不就行？

比如拆很个微服务，就能更多的进行复用，提高生产效率？复用不是系统要追求的目标。很多人认为更多模块的【复用】，就能像乐高快速搭建系统，但很多复用不是乐高，而是器官移植！不仅不能提高效率，还得面对各种排异反应，降低速度和稳定性。很多创业公司快速发展时系统腐化的主要问题就出现在强行复用，如：

• 上百个字段的数据表(如订单表，数据表)，不清楚哪个字段在哪个场景下有效
• 根据名词来设计系统，出现业务中台，如订单中台，电商中台，各部门之间不断扯皮
• 出来无数个小微服务，然后搞个统一的业务编排调度层 (gateaway)处理业务，可能还抽象DSL；上线复杂，需发布N 个模块，调度模块是系统大单点，稳定性迭代速度都是问题

如果有一个好的设计，谨记《Hints for Computer System Design》中的 Use a goodidea again instead of generalizing it. A specialized implementation of the idea may be muchmore effective than a general one.

7 系统设计好的标准是啥?

两个评价标准自治性和一致性：

• 自治性：受其他模块的影响程度，观测模块的接口是否稳定。可使用AutonomyMetrics衡量
• 一致性：应该使用一个模块的地方使用一个模块的程度，也可以衡量是否过早，过度抽象了。可用ConsistencyMetrics

在业务层次是否要从多个业务模块中抽象出一个底层模块，可以通过多个业务模块的这部分公共逻辑部分是否要一起进行改变进行判断，如果不是需要一起变化的就不要抽象出公共模块。

根据个人经验，如果你在要从各个业务模块进行抽象出一个模块保持一致与保持在模块保持自治之间犹豫时，要毫不犹豫优先选择【自治】。

8 总结

大部分情况下系统的核心复杂度不会减少， 只是转移，不会因为所有代码一个人写，会比分成两个人写更快，分工是应该且必须的。注意

• 不要为了复用随意通用化，抽象化，复用不是目的。如果要通用化就拿ConsistencyMetrics 来判断是否是抽象合理的
• 不要随意复用其他的模块，自治优先，用 AutonomyMetrics 衡量;如果要复用一定要确保共识和标准优先，形不成共识和标准就不用复用

写在最后

​​公众号​​​：​​JavaEdge​​​ 专注分享软件开发全生态相关​​技术文章​​​、​​视频教程​​​资源、热点资讯等，如果喜欢我的分享，给 🐟🐟 点一个​​赞​​​ 👍 或者 ➕​​关注​​ 都是对我最大的支持。

文章转载自公众号： JavaEdge