腐蚀修补的恢复、发现、协调三阶段

腐蚀最小化和预防都是”防患于未然”，但完全防止腐蚀是一项艰巨甚至不可行的任务，因此还需要修补方法作为最后一道防线。架构修补包括识别腐蚀、从源代码恢复实现的架构、修复恢复的架构使之符合预期架构、协调实现与预期架构这几个环节，对应三个相互联系、相互合作的策略。架构恢复策略是从源代码等低层信息逆向重建架构，具体技术已在[[架构腐蚀与逆向工程恢复架构的价值]]和[[架构恢复的三种过程与两阶段划分]]中详细讨论过。架构发现策略解决的是”预期架构的文档和规格根本不可用”这一更棘手的情况——此时不能靠”恢复”（恢复的前提是有一份预期架构可对照），而要靠”发现”：通过研究系统用例，从系统需求出发反向构建出预期的架构。例如Heimdhal等人的方法先用Component-Bus-System-Property方法把需求转换成一个架构（用组件、连接件、配置、属性四个通用架构元素刻画），再用标准工具从源代码生成类图、通过迭代聚类算法从中抽取出另一个架构，最后把这两个不同来源的架构模型整合起来，生成一个可重用的架构——这个”需求推导的架构”和”代码抽取的架构”双向印证再融合的思路，比单纯从代码恢复更能贴近”预期”应该是什么样。但书中明确指出架构发现本身并不足以修复腐蚀，它经常只是作为架构恢复和架构协调的辅助补充手段，而非独立完整的解决方案。架构协调策略是修补实际架构、使其符合恢复或发现出的预期架构的过程，最常见的方法是代码重构——遵循架构设计原则系统性地重新组织源代码，同时不能改变系统的可见行为（这正是本书[[软件重构的定义与需求变更的间接关系]]中定义的重构核心约束），已有Structure-101这类得到广泛应用的支持工具。三个策略的因果链是：先用恢复或发现拿到一份”预期架构应该长什么样”的参照，再用协调（代码重构）把实际架构拉回去符合这份参照——正因为架构协调有明确的输入输出、又能复用成熟的重构工具链，书中指出它因广泛的适用性和自动化程度已经在工业界得到应用，是三个修补策略中落地最好的一个。