1.6 随处可见的随机复杂度

下面通过案例说明随机复杂度的表现形式。

案例1：如图1-5所示，服务A和服务B调用服务S，开始的时候一切正常，相安无事。后来，增加的服务C也调用服务S，这时发现服务S有一个实现上的缺陷。此时，理论上应该修改服务S，但由于负责服务S的团队怕影响其他现有服务，因此缺乏解决该问题的动力，或者由于负责服务A的团队正忙于其他新特性的研发，因此服务C的团队不得不“曲线救国”，在自己的服务C中实现变通。一段时间以后，服务B也发现了服务S的缺陷，同样也是自己采用了变通方法。但是服务B和服务C采用的变通方法可能并不相同，这就为以后的维护挖了“坑”，这些都是在积累系统的随机复杂度。

案例2：团队成员因为个人喜好，在一个全部是Java体系的系统中加入Node.js的组件，这对于其他不熟悉Node.js的成员来说，就是纯粹多出来的随机复杂度，而且一旦引入后面再想去掉就难了。

案例3：团队的不同成员为了快速实现通用功能，使用了能实现相同功能的不同组件，或者即使使用了相同的组件，但是使用的组件版本也各不相同，这种不一致性也直接产生了本不应该存在的随机复杂度。

案例4：团队新人不熟悉系统，但急于实现一个新特性，又不想对系统其他部分产生影响，就会很自然地在原有代码的基础上添加if-else判断，甚至直接复制代码并在复制的代码上做修改，而不是去调整系统设计以适应新的问题空间，这种做法看似“短、平、快”，实则引入了随机复杂度，为以后的维护挖了“坑”。

案例5：缺乏领域建模，同一个业务领域概念在不同模块中使用了不同的命名，但是领域内涵完全一致。更糟的是，在不同模块中的实现又不同，各自还加入了差异的属性，这样，后续对模块的理解和维护成本都会变得更加复杂。

案例6：由于项目时间紧张，因此设计的变更直接在代码上修改，使得设计文档和实现不匹配，这也是增加随机复杂度的一个重要因素。

类似的例子，笔者相信你们可以列举更多。

随机复杂度是我们需要重点关注的，其中的短视效应表现为急功近利，这种做法会快速增加系统的技术债务使架构腐化加速，由此造成后续研发认知负荷的增加，更多的协作也会造成协同复杂化，进而降低研发效能。当研发效能降低时，工程师就更倾向于使用急功近利的奇技淫巧来实现交付业务，最终形成恶性循环。