代码评审的长期维护：升级、备份与迁移的顺序

评审记录是团队知识的载体，三个月后翻记录比翻文档有效

把升级、备份、迁移这三件事流程化，才敢长期用。

先说结论

升级前先备份，备份后先演练恢复；不能回滚的升级不做。

• 固定版本，改动前记录当前版本号
• 升级前：备份数据 + 备份配置
• 升级后：验证核心功能，不只看进程
• 迁移：先迁数据，再迁流量
• 回滚方案写在纸上，别只存在脑子里

升级策略

把格式问题交给 lint 后，人工评论里讲空格的占比能从三成降到 5% 以下。

备份的三层

三层分别是：数据备份、配置备份、以及「能重建这台机器」的文档。缺第三层，前两层迟早用不上。

这个服务的几个维护事实

和它自身机制相关的几条：

• 评审等待超过一天，上下文切换的成本会让作者宁愿推倒重写
• 把格式问题交给 lint 后，人工评论里讲空格的占比能从三成降到 5% 以下
• 评论要区分「必须改」和「可以讨论」，否则作者无法判断优先级
• 同一个 PR 混入重构和功能改动，diff 会放大 2-3 倍

迁移的步骤

同一个 PR 混入重构和功能改动，diff 会放大 2-3 倍。

• 新机器按文档重建环境，验证空跑
• 同步数据，做一次一致性校验（条数、校验和）
• 切换前用 hosts 指向新机器验证
• 切换 DNS 或反代，保留旧机器一周
• 观察日志与错误率，再决定是否下线旧机

维护日历

每月：看磁盘与日志；每季：升级 + 备份校验；每半年：恢复演练一次；每年：清理不再需要的服务。

还有几处容易忽略的

都是小地方，但出问题时往往就卡在这里。

• 单次评审超过 400 行时缺陷发现率明显下降，超过 1000 行基本只剩风格意见
• PR 攒了一周才提，两千行 diff 没人看得下去
• 只评论「这里可以更好」不说为什么，作者改不动
• 在 PR 里顺手重构无关文件，真正的改动被淹没

长期维护的秘诀很土：每次只改一件事，改完就验证。