基于度量的架构重构：从未达成指标定位缺陷

基于度量的架构重构方法把架构持续演进原则的达成性度量结果作为重构的”入口”：先对当前演进版本做持续演进原则达成性度量，各子指标取值范围都是[-1,1]，大于0表示演进过程达成了该子指标（越大越好），小于0表示未达成（越小越差）——重构过程选择度量结果小于0的子指标作为重构目标，即哪个指标没达标、就针对哪个指标定位缺陷、给出重构建议，重构后再重新度量，如果仍有子指标未达标就进行下一轮重构，直至所有子指标都满足要求，形成一个迭代循环。六个子指标各自对应不同的架构缺陷成因：主体维持原则未达成，说明组件和组件间依赖关系变动太大（要么组件不变但依赖关系剧变，要么组件本身发生了变化）；平滑演进原则未达成，说明组件规模平均变化率过大（组件本身规模变动大，或组件被大量增删）；组件规模最小化原则未达成，说明组件平均规模过大（组件数量与软件规模的比例失衡）；模块独立演进原则未达成，说明组件依赖图中边数节点数比值过大（组件间依赖关系过于复杂）；外部接口稳定原则未达成，说明外部接口变动太大；复杂性可控原则未达成，说明圈复杂度平均密度过大。书中进一步把六个子指标分成两类：组件规模最小化、模块独立演进、复杂性可控这三个能给出具体重构建议（分别对应拆分/提取组件、降低文件间耦合度、降低圈复杂度三种具体操作）；主体维持、平滑演进、外部接口稳定这三个只能给出”缺陷点”，交由软件设计人员判断是否需要重构——原因是这三个指标衡量的”变动”本身可能对应着合理的功能性改动，无法靠自动化分析判断这些变动是有用的演化还是有害的漂移，因此不能直接给出”减少变动”这种一刀切的建议。这个”能自动给建议 vs 只能给缺陷点交人判断”的二分，揭示了度量驱动重构方法的一个根本边界：凡是能纯粹从结构指标推导出”改善方向”的，可以自动化；凡是需要判断”这个变化本身是不是合理的业务演化”的，就必须留给人。

结构图：

flowchart TD
    A[架构持续演进原则<br/>达成性度量 -1到1] --> B{度量结果<0?}
    B -->|是，未达成| C[识别对应架构缺陷]
    B -->|否，已达成| G[无须重构]
    C --> D{能否自动给出<br/>具体重构建议?}
    D -->|能：组件规模最小化<br/>模块独立演进/复杂性可控| E[自动生成重构建议<br/>拆分组件/降低耦合/降低圈复杂度]
    D -->|不能：主体维持<br/>平滑演进/外部接口稳定| F[反馈缺陷点<br/>由人工判断是否重构]
    E --> H[实施重构]
    H --> A