架构维护的偏离风险与恢复困境

拥有一个软件架构，和拥有一个文档良好、组织良好、维护良好的架构，是完全不同的两件事——若没有后者，架构会不可避免地随时间偏离原来的设计方向，这种风险会导致原本精心设计的架构在实现过程中发生不可弥补的错误。人为评估”架构在实现时是否维持了设计初衷”是一项极其困难的任务，因此业界一直在探索用工具对已实现的系统做”架构提取”，通过反向抽取实际架构来检查它是否偏离了原始设计——但即使有工具支持，这项技术依然不简单，原因有三：许多软件系统本来就没有对架构做过有效的文档化描述；开发人员往往习惯直接通过阅读源代码来理解架构，而不依赖文档；即使存在描述架构的文档，开发过程中的软件变化往往也没有被同步记录下来，导致文档和实际架构逐渐脱节、不再同步。更深层的困境在于：架构中的”层”“子系统”“功能模块”这些概念，很多时候只存在于架构师或开发人员的脑海里，代码文件本身根本没有直接对应的载体能体现它们——面对这个问题，架构师常见的补救办法是靠文件或目录的命名约定来暗示架构结构，但这种办法终究是不彻底的，因为命名约定不是强制约束，代码演化过程中命名和实际结构完全可能逐渐脱节而无人察觉。这段内容揭示了一个和[[康威定律：架构结构与团队组织结构的双向映射]]互为呼应的问题：架构结构既依赖组织结构去维持，也依赖文档和工具去维持，任何一环缺失，架构最终都会退化成”只存在于最初设计文档里、和实际代码毫不相干”的摆设。