编写可维护软件的不朽代码随想-8

保持架构组件之间的平衡

构建封装边界是设计软件架构的重要技能。

原则：

平衡代码中顶层组件的数量和体积。

保持源代码中组件的数量接近于9，并且这些组件的体积基本一致。

平衡的组件可以帮助定位代码，并且允许独立对组件进行维护。

四种情况：

1. 所有修改都发生在一个单独的巨大的组件中

2. 大多数修改都发生在一个单独的巨大的组件，也有几个小组件存在

3. 许多修改分散在多个组件中，多个组件，大小参差不齐。

4. 对一两个范围有限的组件独立修改，体积比较一致的多个组件。

平衡组件的好处：

能让查找和分析代码变得更加容易。平衡不好的组件容易出现不清晰的功能边界，比如一个相对而言巨大的组件，包含了许多无关的功能，导致对它难以分析。

能隔离维护所带来的影响。它能够正确地分离关注点，有利于形成系统中各个组件的独立行为，能避免一些未预料的影响， 比如回归问题。

能分离维护职责。当系统有太多或太少的组件时，会增加我们理解和维护的难度。如果组件数量太少，就无法很容易地了解整个系统，数量太多又会让你很难对整个系统有一个清晰的概览。

如何使用该原则？

确定将功能合成组件的合适原则。软件系统会根据高层的功能领域（描述了系统为用户提供了何种操作的功能）来进行组织，而另一种时按照技术专长进行划分。

例如，基于功能领域划分的系统，可能会有资料检索，发票管理，报表，管理员等组件，每个组件都包含了提供端到端功能的代码，涵盖从数据库到前端的范围。基于功能的划分好处是可以在设计阶段就进行，不用等到开发阶段。对于开发人员来说，可以从高层功能的角度来分析代码。不好的是，可能需要熟悉多个技术领域，才能对某个组件进行修改。

基于技术划分的系统，可能会有前端，后端，接口，日志等组件，好处是团队能够按照技术专长来划分职责，这样的组件划分反映了不同专业之间劳动力的划分。

明确系统的领域并坚持下去。一个不能保持一致的架构不是好架构，一旦组件的划分方式确定下来，就要始终保持在控制中，虽然制定设计方案是架构师的职责，但在代码中创建并考虑组件边界需要每个开发人员的努力。

 

常见反对意见：

组件不平衡没什么影响。平衡有不同的程度，究竟是否会对实际的维护造成影响，取决于偏离的程度如何，维护团队的经验以及不平衡的原因。开发人员不将代码放到对应组件中时，组件不平衡会对维护造成最大的压力，不一致就无法对结果可预测，可能会导致无法预料的影响。放在错误组件中的代码，可能会导致组件中形成错误的依赖关系，从而降低可测试性和灵活性。

组件之间的混乱会降低平衡度。这是指向了另一个问题，组件之间的技术依赖，组件的混乱说明没有恰当分离关注点。

 

SIG评价组件平衡

通过2个指标计算结果的结合来定义和测量组件平衡性：

顶层系统组件的个数；理想是9，顶层组件数量的分数分布从0到1，含有9个的分数为1，一次递减直到只有一个组件的分数是0，对于超过9个的会有一个修正分数，以避免高于17的系统评分均为0，修正分数是基于基准评分95%的分数得出的。

组件大小的一致程度。组件之间代码的分布程度，修正基尼系数作为组件大小统一程度的测量标准，从0（完全相等）到1（完全不相等）的分数，要达到4星，修正基尼系数不超过0.71