web

架构演进与重构策略

第 42 章 · 软件工程

架构是长出来的，不是一次画完的。 需求会变、技术会变、团队会变，架构也要随之演进。演进式架构把「可持续演进」当成设计目标，用fitness function（适应度函数）在 CI 里自动检查架构约束是否被破坏。大规模重构要分步、控风险：评估范围、小步快跑、测试与回滚预案。架构决策记录（ADR）把「当时为什么这么选」写下来，留下演进历史，方便后来人理解与迭代。本章把这几块串起来讲。

一、架构不是一次性的

很多人以为架构是「一开始设计好就定了」，其实架构会随业务、技术、团队不断变化。初期可能单体就够，后来要拆微服务；先上一套存储，后来要加缓存、换读写分离。若把架构当成「一次性交付物」，很容易出现：要么早期过度设计、要么后期改不动。正确心态是：架构是持续演进的，设计时要为变化留余地（模块边界清晰、依赖方向可控），并在演进过程中用文档与自动化守住约束。

架构随时间演进：单体 → 加缓存 → 拆服务 → …

二、演进式架构与 Fitness Function

演进式架构（Evolutionary Architecture）强调：架构要能持续、可控地演进，而不是「一锤子买卖」。做法包括：模块化与边界清晰（便于局部替换）、少做不可逆的大决定（技术选型留替换空间）、用自动化约束架构。

Fitness function（适应度函数）：把「架构要满足的约束」变成可自动检查的指标或测试。例如：依赖关系不能出现循环、某模块不能依赖某层、包/服务耦合度不超过阈值、延迟/吞吐的回归测试。在 CI 里跑这些检查，一旦代码或依赖违反约束就失败，防止架构漂移。Fitness function 可以是静态分析（依赖图、圈复杂度）、测试（契约、性能）、或人工评审的检查清单；关键是要可执行、可重复。

Fitness function 在 CI 中守卫架构约束

三、大规模重构的步骤与风险控制

大规模重构不能「一把梭」：要先评估范围与依赖（动哪里、影响哪些调用与数据）、拆成小步（每步可发布、可回滚）、每步都有测试与回滚预案。常见步骤：建立测试与基线 → 识别重构边界与顺序 → 小步重构（提取接口、搬代码、改调用）→ 每步提交与验证 → 收尾清理。若涉及数据或接口变更，要兼容与迁移方案（见发布与数据章节）。

风险控制：功能开关或特性分支控制新逻辑上线；灰度与回滚预案；重构期间保持「可发布」状态，避免长期 feature 分支。关键是把「大重构」拆成「很多小重构」，每步都安全、可逆。

1. Assess scope 2. Add tests 3. Small steps 4. Verify each step 5. Rollback plan
大规模重构：评估 → 测试 → 小步 → 每步验证 → 回滚预案

大规模重构要点

  • 评估范围与依赖，拆成可发布、可回滚的小步
  • 每步有测试与验证，功能开关/灰度控制风险
  • 保持可发布状态，避免长期大分支

四、架构决策记录（ADR）与演进历史

架构决策记录（Architecture Decision Record, ADR）是一种轻量文档：记录某次重要架构决策的背景、选项、决定与后果。典型结构包括：标题、状态（提议/已接受/已废弃）、背景（为什么要做这个决定）、选项（考虑过哪些方案）、决定（选了啥）、后果（带来的影响与后续注意点）。ADR 不替代设计文档，而是补上「为什么」与「当时怎么想的」，方便后来人理解和在演进时不误伤初衷。

演进历史：把 ADR 按时间或主题组织，就形成架构的演进史。新同学 onboarding、做重构或重评估时，可以顺着 ADR 理解历史；废弃或替代某决策时，可新写一篇 ADR 并标记旧 ADR 为 superseded。这样架构不是「黑盒」，而是可追溯、可讨论的活文档。

演进式架构
架构可持续演进；模块边界清晰、少不可逆决定、用 fitness function 自动化约束。
ADR
记录决策背景、选项、决定与后果；留下「为什么」，方便理解与演进。
演进式架构与 ADR

ADR 常见结构

  • 标题、状态（Proposed / Accepted / Deprecated / Superseded）
  • 背景（Context）：为什么要做这个决定
  • 选项（Options）：考虑过的方案与利弊
  • 决定（Decision）：最终选择
  • 后果（Consequences）：影响与后续注意点

一句话： 架构会持续演进，不是一次性的。演进式架构用清晰边界与fitness function守住约束；大规模重构要小步、可发布、有回滚。ADR记录决策的为什么与后果，留下演进历史。

小贴士： Fitness function 不必一开始就很多，可从「最痛」的一两条开始（例如禁止某层依赖某层、或关键接口的契约测试），再逐步补充。

五、小结

架构不是一次性：随业务与技术演进，设计要为变化留余地。演进式架构：模块化、少不可逆决定、fitness function 自动化守卫。大规模重构：评估、小步、测试与回滚、保持可发布。ADR：记录背景、选项、决定与后果，形成演进历史。下一章进入软件工程伦理与职业责任，从技术对社会与用户的影响到隐私、安全与职业操守。