软件架构腐蚀的定义与三类控制方法框架

软件架构在其生命周期中随系统演化必然会发生变化，这种变化有两种截然不同的走向：一种是架构向更好方向变化，很多质量属性变好——这是所有人都期望看到的正常演化；另一种是原来能保持的架构属性（尤其质量属性）变差甚至不再保持，这就是软件架构腐蚀。软件架构腐蚀准确的定义是”预期或概念软件架构与实际软件架构之间的偏离”——意味着最终实现没有完全满足预定计划、或违背了系统的约束和规则；书中特别强调这种偏离更多源自日常的软件修改，而非人为恶意——也就是说腐蚀通常不是某次”破坏性改动”造成的，而是无数次看似合理的局部修改累积偏离预期架构的自然结果。腐蚀会导致工程质量恶化，包括功能性、性能、完整性、一致性、可理解性、可维护性与演化性等重要特性的丧失。针对腐蚀问题，控制方法可分三大类，各自作用于腐蚀发生的不同时间点：腐蚀最小化（旨在抑制腐蚀的发生率，包含面向过程的架构一致性、架构演化管理、架构设计实施三个策略）——作用于腐蚀发生之前，降低发生概率但不能彻底杜绝；腐蚀预防（集中于杜绝和根除腐蚀，包含联动架构和自适应两个策略）——同样作用于腐蚀发生之前，但目标是从机制上彻底阻止腐蚀发生，而不只是降低概率；腐蚀修补（针对已因腐蚀引发的损害进行修复，包含架构恢复、架构发现、架构协调三个策略）——作用于腐蚀已经发生之后，是最后一道防线。三者的关系是递进而非互斥：最小化和预防都是”防患于未然”，只是介入的彻底程度不同（最小化降低概率，预防试图根除）；修补则承认”完全防止腐蚀是一项艰巨甚至不可行的任务”，是在前两道防线都没能完全生效之后的补救手段。

结构图：

flowchart LR
    A[架构演化] --> B{偏离预期架构?}
    B -->|否，正常演化| C[质量属性变好]
    B -->|是| D[架构腐蚀]
    D --> E["腐蚀最小化<br/>降低发生率<br/>（一致性/演化管理/设计实施）"]
    D --> F["腐蚀预防<br/>杜绝根除<br/>（联动架构/自适应）"]
    D --> G["腐蚀修补<br/>事后修复<br/>（恢复/发现/协调）"]