以下文章来历 原创齐光[阿里云开发者]
阿里妹导读
本文剖析「复用性」这一概念背面的危险及成因，凭借笔者在事务安全和根底安全的经历，提出了一个在软件研制流程中，办理「复用性本钱危险」的危险办理模型，希望能为读者在后续的技能决议计划和软件研制流程供给少许帮助。复用性（Reusability）是软件工程中一个被频频运用的术语，它一般作为产品的卖点被宣传，或许呈现在技能规划文档之中。大部分看到这个概念的的受众仅仅将其作为一个积极的软件非功用特点去理解，但却疏忽了其背面躲藏的危险。本文从另一个视点动身，去剖析「复用性」这一概念背面的危险及成因，凭借笔者在事务安全和根底安全的一点经历，提出了一个在软件研制流程中，办理「复用性本钱危险」的危险办理模型。从模型动身，咱们能够知道到完成复用时面临的各项应战、开发认知过错、复用本钱的形式化界说办法等，希望这些输入能为读者在后续的技能决议计划和软件研制流程供给少许帮助。本文首要分为三个部分：第一部分介绍复用性的界说以及不合理复用引进的首要技能债，第二部分剖析复用性失效的原因；第三部分为复用性软件财物的构建方和运用方供给一个形式化的衡量东西，该东西将奠定后续危险办理模型评价阶段定量剖析的根底；第四部分提出一个用于办理「复用性危险」的模型，掩盖软件研制生命周期的全流程，经过事前评价、事中缓释和过后迭代三个环节最大程度地下降由于软件复用带来的软件开发和保护本钱。
一、复用性的抱负与现实
1.1 复用界说：从代码到体系
软件复用是解决软件质量和生产力问题的一种办法，它指的是在软件开发进程中重复运用相同或类似的软件元素。经过合理运用软件复用技能，咱们能够进步开发功率，而且下降开发进程中的过错率。一起，软件复用还能够促进团队协作和常识同享，使得开发者们能够更好地运用互相的经历和资源。因而，在当今快节奏的开发环境中，软件复用现已成为进步生产力和质量的要害战略之一。在过去几十年的时刻里，许多编程言语的成功（Python、Java 等）和开源文明的蓬勃发展，都与复用密不可分。软件复用能够在不同粒度上进行，包含代码和规划仿制、源代码复用、规划和软件体系结构复用以及范畴特定的软件体系结构复用等。前期的软件复用首要会集在代码等级，例如同享办法、笼统类、库、微服务和Docker镜像等。跟着时刻推移，其外延拓宽至范畴常识、开发经历、规划文档、需求剖析和测验用例及数据等在不同阶段所发生的各种软件产品。在本文中，除非特别阐明，复用性首要指的便是聚集代码的复用，下文中的「组件复用」，不只限于一般咱们认知中的公共库，还包含代码办法、公共类、软件结构、可集成体系等软件开发中的可复用元素。
1.2 复用危险：复杂度和本钱
固然，经过组件的复用能够进步软件开发功率和质量，但复用不是银弹，复用也会有一些副作用：
1.兼容性/安全性/功用；2.添加了体系间的依靠；
3.添加了开发和保护本钱。
首要，兼容性/安全性/功用等这几类问题，是针对可复用组件的运用方来说的，一般来说，在决议计划是否复用之前就能够评价，其目标和进程也比较明晰，这儿就不详细展开了。
其次，复用会添加体系依靠。 依靠联系是软件的底子组成部分，无法消除，但软件规划的方针之一是尽或许消除依靠联系，并使依靠联系尽或许简略和显着。当咱们引进外部组件进行复用时，软件组件之间的依靠联系会导致组件改变规划的扩展以及组件认知负荷的添加，前者是针对组件保护方而言的，即看似简略的改变需求在许多不同的当地修正代码，跟着顾客数量的添加，在不同需求之间进行平衡变得越来越困难； 后者是关于组件运用方而言的，即开发人员需求了解许多组件范畴常识才干完成有用的组件复用。比方，需求了解待运用接口中若干入参的规划目的、是否存在隐式依靠传递然后导致依靠抵触等。依靠的添加会为体系引进更多的复杂性，而咱们知道，构建软件体系的中心应战便是办理复杂性，复用组件只会在必定程度上搬运复杂性，但并不能消除复杂性。因而，咱们需求在「复用组件下降本钱」和「复用组件引进依靠（复杂性）」之间获得平衡。
终究，复用会添加各项本钱。 包含开发的本钱、改变的本钱、集成的本钱、范畴常识搬迁的本钱。关于一个面向复用规划的组件来说，完成正确笼统和通用结构的规划和开发本钱，比一次性的解决方案高得多，关于组件的后续保护者来说，这样的可复用结构和库一般也会带来峻峭的学习曲线（由于文档一般是缺失的），组件会逐步走向堕落，终究不得不推倒重来。此外，关于可复用组件的运用方来说，其理解和集成组件的本钱一般也是被疏忽的，一些强推的事务层的「伪复用结构」给前台集成的同学带来了巨大的集成、学习和保护本钱。
上述复用带来问题，有一些是能够躲避的，如兼容性、功用、容量等的匹配度，有一些是无法防止的，如规划通用化组件的开发本钱、不合理的笼统导致的代码堕落、不合理的复用导致的保护本钱等。事实上，不管咱们在技能上做多么精妙的规划，技能的立异永久滞后于体系的堕落速度。
为了最大程度的下降复用带来的危险，本文提出一套从类比于安全危险办理的「复用性危险」应对模型，从事前评价、事中缓释、过后迭代三个阶段动身，最大程度地下降咱们在开发可复用组件、运用可复用组件中遇到的各类危险。需求阐明的是，上面以及后面指的「复用性危险」，界说为「由于不合理的复用决议计划，导致依靠和复杂度膨胀过快，然后导致软件保护本钱过高」的问题， 除了本钱危险外，由于复用组件的不合理运用或存在的缺点而导致的兼容性、安全性、功用等方面的危险，其危险更为显著和易于办理，因而不是本文论述的要害。此外，复用开发进程中的开发方针偏移、迭代和发布计划的延期、人员短缺等危险，限于篇幅也不在这儿展开。
第二部分首要会介绍导致「复用进步软件开发功率」这一准则失效的几类首要原因，第三部分会要害介绍用于评价复用性的若干东西，有了对复用性实质的知道后，再第四部分咱们会简要介绍复用性危险办理模型。
二、复用性危险根因剖析
2.1 现实应战：正确和过错的笼统
咱们复用组件的一个初衷，除了是为了进步研制功率之外，也是希望可复用组件能够将范畴的复杂性阻隔在一个咱们永久看不到的当地，然后全体下降组件运用方的体系复杂度。因而，一个可复用的组件，不管其规划巨细，其规划进程便是对某个范畴高度笼统的进程。在规划组件时，向上面对当时或潜在的需求，需求咱们做必定的前向通用规划，向下尽或许屏蔽掉组件的完成细节，笼统的成果直接决议了后续该组件可复用性程度的凹凸（可复用性的衡量将在下一个章节胪陈）。但遗憾的是，杰出的笼统才能关于大部分开发者来说是一个稀缺的产品，它需求对问题进行明晰的界说、简化和分解，一起辨认和运用通用形式，将子问题的解法组合起来构成一个全体解决方案，依靠对规划形式、开源的库和结构、数据结构和算法以及许多生产项目的长时间实践和考虑。
在日常的代码中，咱们不乏笼统，但大部分都是不合理的笼统。过错的笼统构成的损害甚于不笼统，比方常见的一个现象：对规划形式的适用规划知之甚少，仅仅为了炫技而滥用规划形式，导致代码的可读性和可保护性下降。
除了对笼统才能的要求外，许多时分需求紧迫度、开发资源、责任心以及组件地点范畴责任的改变等要素，都会导致可复用组件从出生就带着「高本钱」的原罪，其后续的运用本钱和保护本钱会急剧上升，这儿就纷歧一展开了。
2.2 认知过错：复用不是规划方针
一个关于复用性的认知过错便是，把「不重复」等效为「复用」，这两个概念之间有类似之处，但仍是有一些奇妙的不同。「不重复」即咱们所熟知的 DRY 准则（Don’t Repeat Yourself），其方针是经过削减重复建设然后防止承担副本纷歧致的保护本钱，而 Reusability 是从一切代码中找到重复的部分，然后在复杂度可控的前提下，努力笼统出可复用的东西。一堆不重复的代码，并不代表存在可复用的组件。
复用仅仅完成不重复方针的一种手法，「不重复」才是咱们规划软件体系时的方针，单纯追逐「复用性」许多时分会呈现一些舍本求末的现象。 如呈现了一些接入本钱十分高的自动测验结构、事务中台结构，一味追逐「（我）一次开发，（你）随处运用」，殊不知在运用方需求消耗许多的精力去内化结构规划者的规划初衷，面对十几个接入参数或配置文件束手无策。
举个例子，偶然会看到咱们在事务层代码中，部分同学会把简略的新增和修正逻辑笼统为一个办法，美其名曰「供给给接入层复用」，如下面的 insertOrUpdate 办法中，初看是复用了范畴目标转换和用户目标是否存在的代码，契合 DRY 准则，但实际上却是混用了两个不同的事务语义，会给后续的保护带来较高的本钱，如改变用户信息时，需求做更个性化的用户特点处理，这时分调整范畴目标转换处的代码，将会影响新增逻辑。
更合理的完成是，将显着不同语义的代码进行拆分，尽管看上去存在必定程度上的代码重复，但其规划会更利于后续的功用迭代，也更契合代码的「单一责任」规划准则。
2.3 决议计划误差：复用的决议计划权在哪
代码的复用更多的时分是软件开发者自发完成的，但咱们无法忽视的一点是，怎么集成、是否复用、怎么复用、是否是同一个功用、运用什么粒度的复用，许多时分是由事务架构决议的，「康威规律」仍是无法逃避的。
比方，在一个新的场景里，产品要求把「PPT 上与其姓名相同的一个功用」进行复用，以快速上线，尽管他们除了姓名相同，其产品形状、事务流程、环境依靠等都不相同。终究强行「复用」的成果便是代码逻辑里呈现了许多的分支判别，底层技能架构变得臃肿。由于关于范畴的理解不同，呈现这种状况在所难免。尽管许多时分软件复用的决议计划权并不在开发者这儿，但出于技能情怀也好，责任心也罢，开发者有义务去做这种纠偏，最大程度地消除这种差异性。但需求知道到技能的作用在这儿并不是决议性的，杰出的技能是复用成功的必要非充分条件。
2.4 东西缺失：怎么核算复用本钱
复用性衡量，首要分为两个部分：
1.复费用：决议一个组件复用性凹凸水平的要素有哪些？
2.复用本钱：组件集成方、组件地点的安排，决议实行复用战略后的 ROI 怎么核算？
经过复费用和复用本钱两个目标，咱们能够进行必定程度上的复用性定量剖析，做出更为长远的技能决议计划。比方，能够了解到一个复用性高的组件，其特征有哪些？引进一个新的第三方组件时，除了根底的功用性组件外，我还需求考虑哪些？相较于运用现已存在的组件，是否考虑重新造一个轮子？「复用」和「造轮子」间本钱有多大？关于复用性的衡量东西，第三部分将要害论述。
三、复用性的形式化衡量
3.1 组件衡量：可复用水平的评价
咱们在规划一段代码/一个类/一个模块等可复用的组件时，一些可衡量的软件目标共同决议了组件的可复用性水平的凹凸。这些目标包含：可靠性（Reliability）、可读性（Understandability）、可保护性（Maintainability）、通用性（Generality）与可搬迁性（Portability），如下图所示。每一个目标可由各类代码衡量特点决议，如组件的可搬迁性由「组件的独立性」和「耦合性」两个特点决议，大部分的衡量特点都是能够经过形式化界说并核算出来。不同目标的决议因子及衡量值（括号中）如下：
1.可靠性： 功用（呼应时刻）、容错程度（恢复时刻）；2.通用性： 类泛化水平（子类实例个数或接口完成类个数）；3.可读性： 内聚性（类之间耦合度）、复杂度（圈复杂度）、规划（代码行数）、文档水平（数量+完好度）；4.可保护性： 易于修正、单测和回归测验（测验掩盖度）、组件的独立性（依靠数）、耦合性（类间耦合度）；
5.可搬迁性： 组件的独立性（依靠数）、耦合性（类间耦合度）。
为了衡量整个组件的的可复用性，有必要界说一个可复用性核算模型。该模型依据上图所示的复用性特点模型。首要的可复用性特点、影响这些特点的要素以及衡量这些要素的量度之间的联系显现在这个模型中。理论上，软件组件的可复用性(用Reusability表明)能够用表达式来核算：
Reusability = w1M + w2R + w3P + w4U + w5G*
其间w1 ~ w5为不同目标的权重值，目标M（Maintainability）、R（Reliability）、P（Portability）、U（Understandability）、G（Generality） 值进行归一化（0 … 1）后，乘以每个目标不同的权重值，经过核算得到终究的组件的可复费用。
在上面的剖析进程中，存在部分衡量无法进行定量剖析的状况，但不同因子组合核算仍是有意义的，咱们能够拿这些目标去评价咱们现在的体系，存在的问题的严重程度。当下次他人问咱们为什么要复用组件A而不是组件B时，咱们能够给出更令人信服的理由，而不只仅是「我觉得」、「A比B好许多」等论述。
3.2 安排衡量：复用的投入产出比
对组件的复用性有了一个理性认知后，更加一步地，让咱们从经济的视点去考虑复用性背面的本钱问题。首要，咱们先界说几个变量RL、NUC、RCR、RCWR。
- RL（Reuse Level） ：可复用组件在运用中的份额，即 RL=复用的组件中代码行数/运用总的代码行数；
- NUC（Not Use Cost） ：运用开发进程中彻底不运用可复用组件的本钱，注意不包含后续的保护本钱；
- RCR（Relative Cost of Reuse） ：复用既有的组件与重新造一个类似的轮子，这两者之间工作量的比值，一般在0.03~0.4之间，经历值为20%，即这意味着复用所花费的本钱大约是编写新组件所投入的20%；
- RCWR（Relative Cost of Writing for Reuse） ：开发可复用的组件与开发一次性运用的模块，这两者之间工作量的比值，一般在1.0~2.2之间，经历值为 1.5，即这意味着编写可复用软件需求大约50%的额外本钱。
关于集成方而言，能够核算因复用节省的本钱（DCA，Development Cost Avoidance）以及复用后的本钱节省比占比（ DCAR，Development Cost Avoidance Ratio）：
举例，假定复费用 RL = 40%， RCR = 0.2，则软件集成方节省本钱占比 = 0.64，即节省了64%的本钱。一起咱们能够得到一个简略的定论，关于组件的集成方来说，假定想要进步本钱占比，则需求：可复用组件在项目中的复费用越高越好，一起可复用组件的 RCR 应较低。 这意味着可复用组件拓宽性、可读性需求坚持在一个较高的水平，这样集成方在集成时的二次开发和适配本钱会较低，这个定论也是契合咱们研制时的直觉的。
关于安排而言，假定某可复用组件的N个场景被运用了，则安排复用收益 OROI 可核算如下：
举例：假定复费用 RL = 40%，RCR = 0.2，RCWR = 1.5，复用次数为5次，则 安排收益 OROI = 167%，这意味着开发一个可复用的组件，一起在多个场景进行复用，是有超额报答的。可是不是只需复用了就会有收益呢？另 OROI = (N*(1-RCR) – RCWR)/RCWR > 0 能够得到 N > RCWR/(1-RCR)，带入上面预设的 RCR = 0.2，RCWR = 1.5 这两个值，得到 N > 2，这意味着需求两个或两个以上的场景复用了此组件，咱们此次研制活动才会获得正向的收益。与此一起，咱们能够从上面的公式得到以下几个关于进步安排复用 ROI 的定论：可复用组件在项目中复费用越高越好，开发可复用组件时，RCWR 和 RCR 越低越好。 RCWR 低意味着不要去过度规划，组件的泛化性需求在范畴内得到必定的操控，RCR 低意味着可复用组件可读性好、拓宽性高，集成时的本钱不高。
马丁福勒（Martin Fowler）在《重构》一书提出了一条代码重构经历规律「Rule of Three 」，即咱们能够仿制和张贴一次代码，可是当仿制相同的代码三次时，应将其提取到新进程中进行笼统以便于复用，规律里面的最小重复次数3，其值亦契合上述 N > RCWR/(1-RCR) 的定论。
3.3 重复衡量：复用和仿制的鸿沟
回到咱们第二节中所说到的问题：为什么说 DRY 准则不等价于复用？假定以下场景：1. 项目中规划了大局的字符串常量类，一切的公共常量都放在此处，其他模块中的类都引用此常量，这是一个好的实践吗，是不是界说模块内的常量类或类中的常量字段会更好？2. 我需求进行字符串判重逻辑，是自己重写一个字符串东西类，仍是直接运用如 commons-lang 或 guava 包中的代码呢？上面的场景都没有绝对的答案，但就我现在看到的状况来看，在许多开发者的编码习惯中，由于过度去追逐「复用性」，呈现了一些没有必要的依靠担负，如运用大局常量类，呈现没必要的类加载，第三方包的随意运用，构成运用包膨胀或许集成时的包抵触问题。有时分，仿制一些类似的代码比测验泛化再实例要好得多，过度运用笼统只会模糊真实要害的问题。
那什么时分能够仿制，什么时分不主张呢？除了2.2中说到的语义纷歧致时的适度仿制（就不是复用），当咱们真实运用的代码占可复用组件全体代码逻辑的份额较低时（譬如只运用了 commons-lang 包中的 StringUitls 类），能够考虑重写一份，进行适度的仿制张贴，完成该处逻辑和集成方「自治」。对应前面的定论，这种状况下意味着 RL 较低，一起RCR 较高，比方 RL = 0.01，RCR = 0.8 ，则 软件集成方节省本钱占比只要 RL(1-RCR) = 0.2%* ，这一点收益同后续或许潜在的危险（包膨胀和包抵触）相比，仿制或许是一个更好的挑选。
四、复用性危险办理模型
有了前面两个部分的铺垫，咱们再回头去审视由于复用引进的本钱危险，应该采取哪些办法能使得危险最小化呢？在事务风控和数据安全等泛信息安全的事务中，咱们对危险办理的笼统，都会强调事前、事中、过后的危险操控流程。类似地，咱们能够在代码研制进程中，经过建立事前评价、事中缓释及过后迭代的复用性危险管控手法，下降危险发生的或许性及其构成的影响，并依据事务架构和技能架构的发展趋势采取躲避、下降和搬运危险的办法，将危险操控到团队可承受的水平之内，最大程度地防止或延缓由于复用导致的保护本钱高、体系快速堕落等问题。
事前评价、事中缓释、过后迭代构成的全生命周期复用性危险办理模型如下图所示：
4.1 事前评价：本钱与启发式决议计划
风控的事前阶段（评价+剖析），一般依据某些黑样本动身，挖掘出适用于后续危险对抗阶段的某些危险行为特征或模型，并依据历史样本核算出准确率和召回率。在复用性危险的事前阶段，咱们也能够经过定性和定量的评价手法，尽早发现各种复用时的「坏滋味」，当即予以纠正或防范，把危险消除在萌芽状态，防止由于过错的复用引进过多技能债。评价的流程首要分为：可复用组件评价、复用本钱和收益的衡量、启发式决议计划这三个阶段，详细地：
1.假定待复用的组件是已存在的，则能够核算或预算出已复用组件的可复用水平，考量的目标即上面说到的可靠性、可读性、可保护性、通用性和可搬迁性，不同场景的目标权重纷歧，能够结合详细场景进行判别；2.假定待复用的组件是需求新建的，则能够核算出后续集成节省的人力本钱，以及中长时间的时刻里安排经过复用组件获取的全体收益，经过结合复用本钱、复用收益、当时安排人力现状、后续事务进行终究的决议计划；
3.假定进程1和2都得不到一个终究的定论，下面还有一些启发式的经历帮助咱们决议是否真的需求复用。
或许需求复用的场景（笼统组件或复用既有组件）：
1.待复用的事务逻辑十分专业，如 Json 序列化、加解密；2.相同或类似事务语义的代码现已存在多（3）处，需求重构；3.待选的可复用组件文档十分全面，易于接入、拓宽、替换或移除；4.事务逻辑改变频频，每次改变需求一起改变多个体系或模块以坚持同步；
5.需求即时同享且对纷歧致性容忍度较低的一些事务逻辑单元，如表的元信息。
或许无需复用的场景（那就再造一个轮子吧）：
1.没有文档，或文档质量较差；2.重复造一个不太难，一起保护本钱较低；3.只运用了可复用组件一切功用里的很少一点逻辑；4.要花费许多的时刻去了解可复用组件的规划思路；5.可复用组件在拓宽新功用时，需求投入许多的精力去协同推进；6.可复用组件集成时的适配或拓宽代码，比单独重写该组件的代码还要多；7.可复用的组件是整个运用的中心，且后续事务发展迅速有较多的定制需求；8.可复用组件的产品文档或体系规划中许诺了太多的功用（饼），过于「雄心勃勃」；
9.终究一点：假定决议计划时觉得可用可不用，那大概率也是不需求复用的，信任自己的第一判别。
经过本钱和收益预算，以及若干启发式的决议计划经历，大多数的场景咱们都能够评价得到一个明晰的是否复用的答案。软件复用或许会在短期内进步生产力，但它或许会发生长时间后果，所以这一步需求慎之又慎。
4.2 事中缓释：HCLC&测验&文档
事中缓释阶段是操控复用性危险的中心环节，它首要聚集在可复用组件的开发阶段，经过一系列的要害进程将复用危险在开发或正式运用前尽或许地下降，首要包含下面几个要害：
- 高内聚低耦合
- 单元测验和回归测验
- 完好且有用的文档化
高内聚低耦合（HCLC ）。 这是一个陈词滥调的工作了，内聚和耦合会影响可复用水平中的多个目标，如是否内集会影响可读性和可搬迁性，耦合会影响可保护性、可搬迁性和可读性。软件工程中现已有许多规划准则或形式供咱们挑选了，如在代码开发阶段，优先组合、依靠倒置、里式替换、接口阻隔、单一责任、开放封闭、23种规划形式等，在架构规划阶段，也有若干的架构规划形式或办法论，如分层、CQRS、异步事件驱动、范畴驱动规划等。
完好且有用的文档。 「好的代码是自解释性的」，这句话不彻底对。首要，不管是咱们的架构规划抑或是代码规划，许多东西是无法在代码中体系出来的，如关于范畴笼统的取舍、决议计划的考虑进程等，即便是咱们的的接口、成员变量、完成，其命名和规划进程现已到了一个十分高的水平，代码中「躲藏信息」仍是会损失，而注释能够尽或许去补偿这部分损失。其次，需求知道到：人类的感知与交流速度是很慢且低效的，需求经过文档去添补两边交流时的这一道鸿沟。当然，这儿评论的是一般状况，依托「无文档化」构建中心「竞争力」的行为形式不应归入此类。终究，一个正常的安排，人员是会流失的，大部分人终究都会脱离这个安排，可复用组件的要害规划者假定不在安排里了，这种常识性的损失将是永久性的，文档（注释、规划）起到了一个备份范畴常识的作用。
单元测验和回归测验。 复用理论之所以建立，动身点是咱们希望运用现已存在的、成熟的软件财物来进步研制功率，一起下降体系缺点，一套全面的自动化回归测验，不只要利于集成方，也会让后续和此可复用组件相关的每一个人获益。假定咱们开发的可复用组件没有自动化的回归测验，那这样的组件是不合格的，是不应该发布公共库房的。缺少自动化测验或中心流程自动化测验掩盖度较低的组件，关于集成方和组件后续的保护者来说是一场灾难，它给体系引进的巨大的技能债甚于彻底没有配套文档的可复用组件。
4.3 过后迭代：捕捉范畴改变&安排
在开发可复用组件时，假定一开始就大刀阔斧地投入研制资源，终究或许会创建与直接需求无关的软件财物，并由于规划、开发和测验时刻的添加而发生严重的进展危险，相反，经过屡次迭代改善可复用组件来下降这些危险，一个杰出的组件、结构和软件架构需求时刻来规划、完成、优化、验证、运用、保护和增强。 与此一起，第一阶段的开发和集成完毕后，在迭代的进程中进行继续性的危险办理，能够使得可复用组件的危险坚持在一个较低的水位，尽或许地延长组件的生命力，需求做的首要事项包含：继续捕捉范畴改变以及相应的安排支持。
捕捉范畴改变。 上面说到了，代码中有部分内隐的常识，事实上，一个可复用的组件便是开发者关于某个范畴考虑的成果，不管它是以类文件、模块仍是体系的办法呈现。而范畴都是会改变的，改变包含：范畴的鸿沟会拓宽、范畴内部分实体内在会改变、不同范畴之间的鸿沟会堆叠或许融合等。范畴改变后，假定在这其间的可复用组件没有进行恰当的调整，就会呈现技能和事务配速失效的问题。可复用组件在封装了范畴常识的一起，也必定程度上屏蔽了复杂度，当组件不足以承担起范畴的实体或功用呈现误差时，就会呈现「复杂度泄漏」的问题。
捕捉域改变的两个要害动作：一致范畴上下文以及重视上游需求池。一致范畴上下文重要性显而易见，许多时分各方意见呈现误差的底子原因是咱们没有构成一致交流的言语，无法简略、准确且明晰地描绘各自的诉求。 我在进行某危险域架构办理时，做的第一件工作便是拉上了业产研三方，一致咱们对「规矩」和「战略」两个概念的内在和鸿沟的认知。其次，开发人员和架构师需紧密重视需求池，从需求本身动身，区分范畴中可变性和通用性的要害来历。辨认出问题域中的一切改变是不现实的，咱们能够重视一些要害问题，如面对一个新的需求，能够考虑：
1.咱们评论的概念是否一致？2.该需求触及哪些范畴实体？3.该需求是否需求有咱们新增实体？4.新增实体是否会与既有实体发生二义性？5.之前是否存在类似的需求？有什么不同？6.新增的需求是否能够和既有的逻辑进行阻隔？
7…….
是否有一种辅导准则，能够让咱们在跟踪这些域改变的时分，进行更合理的规划与取舍呢？熵增原理告知咱们：一个孤立的热力学体系的熵不减。关于体系的可逆进程熵不变，不可逆进程熵添加。因而，类比软件工程范畴，在组件的过后迭代阶段，一个尽或许消除代码规划/软件架构中熵增的规划准则：在既有组件中新增的功用点需求存在逆向的删除机制，这样就能够尽或许让可复用组件跳出逐步紊乱无法保护的宿命。功用可逆的详细操作详细能够表现为：SPI 机制（Service Provider Interface ）、面向接口的编程、经过模块阻隔随机的或一次性的需求等。
安排和配套的文明。首要，安排是事务架构的投射，当复用组件内的范畴实体和安排担任的范畴实体呈现误差时，就会呈现因错位发生的技能债，成果无非是两种：一种是之前的可复用组件直接被扔掉，任由其自生自灭；另一种缺少背水一战进行重构勇气与担任，既然不是我担任的，那就改一改重新用，原先一致均衡的结构会快速打破。其次，可复用组件和结构的好坏取决于构建和运用它们的人，咱们需求能评价危险和机遇的办理者，需求能辨认范畴实质复杂度和偶然复杂度、一起能很好把握规划形式和架构形式的架构师，以及，在开发准则、形式和实践上经历丰富的开发人员，组件是否可复用、能够复用多久，很大程度上是具有杰出规划和经历丰富的开发人员的副产品。再者，在过后迭代阶段，咱们需求专门的团队或担任人为此可复用财物担任，不断监控渠道代码库的健康，跟踪和修正过错，坚持正确笼统，不断完善文档。当然上述仅仅抱负状况，更多的时分，这样的人或团队是不存在的，或许即便存在，相应的安排鼓励也是缺失的，在一个没有复用的文明土壤中，组件堕落仅仅时刻问题。终究，有了正确的安排和优异的人，长时间的信心、热情、鼓励以及办理层的支持与呼应，也都是成功的复用必不可少的条件。
五、关于复用的一点感想
本文想要害去表达的几个观念：不要过度去追逐「复用」、可复用的水平以及复用投入产出比是可量化的、可复用财物是内隐的范畴常识、适度的重复也是可接受的、文档能够补偿范畴常识的损失、架构演进中新增功用需可逆。
编撰此篇文章的初衷，一方面源于近几年来在辅导新同学时，发现呈现较多的「伪复用」现象，例如为了削减代码，将同享的办法签名放在接口中，构成「进程式接口」，另一方面，自己也写过一些「为了复用」而规划的组件或模块，从中间件到事务组件大概有十几个了。但最近逐步开始意识到，许多时分为了后续的可搬迁性，一些架构或代码层的的前向防御性规划作用并不大，过度笼统反而是给运用方构成了一些理解上的困难。到底哪些真的需求复用，哪些能够妥协，梳理完这篇文章后，坚决了一部分想法（例如全程文档化），也给一些既有观念做了纠偏。
上面也一直在传递一个观念，好的软件财物是一个优异团队的副产品。当把复用的目光从软件聚集到人，咱们自己身上，哪些是能够复用的，哪些又是渠道或安排赋予咱们的？去除去那些光怪陆离的虚幻部分，不可变的部分又有哪些？授权后的高价值专利算一种，其有用期为二十年。考虑进程中沉淀或许算另一种，它们或多或少且阶段性地概述了当时的所思所想，不管内容是否全面、正确，也涂改上了韶光的颜色，这也是这篇文章发生的另一个动机。
