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

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

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

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

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

　　自治性：受其他模块的影响程度，观测模块的接口是否稳定。可使用AutonomyMetrics衡量

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

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

　　不要为了复用随意通用化，抽象化，复用不是目的。如果要通用化就拿ConsistencyMetrics 来判断是否是抽象合理的

　　，我会第一时间和你分享软件行业趋势，面试资源，学习途径等等。添加好友备注【技术群交流】拉你进技术交流群