在较大的团队中，每个 PR 都会由至少一名其他工程师审查。而在 Sage Ideas，我是唯一的工程师。没有人审查我的代码。
这是个问题。不是因为我写得差——而是因为我看不到自己的假设。每个开发者都如此。
我开发了一套自我审查流程，能捕捉到大多数本应由第二双眼睛发现的问题。它并不完美，但远比"看起来不错，合并吧"要好得多。
24 小时法则
我从不审查今天写的代码。写作和审查之间至少间隔 24 小时。理想情况下是 48 小时。
这听起来很慢。实际上很快。在这 24 小时里，我在构建其他东西。当我回来审查时，已经部分忘记了自己的实现。这种遗忘正是关键——它让我能像读别人写的代码一样阅读。
审查清单
我分 4 轮进行审查。每轮关注不同方面：
第一轮：像用户一样阅读（5 分钟）
不要看代码。打开 PR 差异，只读文件名和行数。
问题：
- 仅从文件名看，这个变更合理吗？
- 涉及的文件是否太多？（耦合变更的迹象）
- 是否有不该出现在本次变更中的文件？
第二轮：阅读逻辑（15 分钟）
现在阅读代码。但不要检查风格、命名或格式。只看逻辑。
问题：
- 正常路径能工作吗？
- null/undefined 输入会发生什么？
- 是否有静默失败的情况？
- 我处理了错误情况，还是仅仅记录日志然后继续？
- 是否存在竞态条件？（尤其在异步代码中）
第三轮：阅读安全性（10 分钟）
\\
