我拒绝在没有适当的代码审查流程的情况下在团队中工作——你也应该这样做！

当我以自由职业者的身份为客户工作时，我拒绝与没有合理代码审查流程的团队合作。我想告诉你原因，但首先让我们先来看看我对“合理代码审查流程”的定义：

• 所有功能、错误修复、热修复或其他任何内容都在分支上开发（功能、开发人员……由您决定）。任何代码都不会直接推送到主分支！

• 事实上，您的主分支应该受到保护，将更改合并到主分支（开发，...）需要至少一位同事的批准

• 团队中的每个人（从实习生到领导）都会定期花时间（！）甚至被鼓励进行代码审查

• 所有参与人员都会认真对待评审！切勿在未实际审核代码的情况下轻率点击“批准”按钮。如果您选择的评审员现在时间紧张，请提醒他稍后再做，或者如果情况紧急，请咨询其他同事。

• 仍然需要审核的拉取请求不会因为“有更重要的事情”而“堆积如山”。同时打开几个拉取请求是可以的，但一个只有 5 名开发人员的团队不应该同时打开 50 个 PR。根据我的经验，每个开发人员同时打开 2-3 个 PR 应该没问题，并且仍然可以进行适当的审核，但这当然很大程度上取决于 PR 的大小。

• 拉取请求尽量简短。React 项目中，一个 PR 最多包含 15-20 个文件。有时你无法避免这种情况，但请至少尝试一下。

我拒绝在未经审查的情况下将我的代码合并到主分支（并随后将其投入生产），原因如下：

1. 可维护性！🍎 对我来说非常清晰的代码，在其他人看来可能非常令人困惑。代码评审可以（而且通常确实）非常有帮助，可以让复杂的部分变得更简单。

2. 责任！📜 如果我犯了一个非常明显的 bug，无论出于什么原因，测试都没有覆盖，而它最终投入生产，那么我就是这不幸事件的唯一责任人。如果能得到其他人的批准，就能把责任分摊一半（甚至更多）。尤其是当你像我一样，是个承包商，可能会因为疏忽而承担责任时，这样的审查就至关重要了，总有一天会救你一命。（我说的是“可能”，而不是“将要”！）

3. 文档！📋 我通常会写一个简短易懂的描述来描述我的 PR 中发生的事情。如果之后你（或其他人）对某些内容不确定，如果文档/自述文件中没有明确提及，你可以在旧的拉取请求描述中找到答案。

4. 可持续性！🌿 一个每个人都可以随意提交未经审查的代码库通常看起来就是这样：就像没人在乎一样。这是不可持续的，最终必然会导致灾难。

5. 降低风险！🛡 有时你会独自开发一个相对复杂的功能好几天。通过让另一个人审查你的代码，这个人必然会了解这一切的意义所在。这已经可以极大地降低你的巴士因素了。

6. 学习！🎓 作为一名开发者，你只有定期接收和提供代码反馈才能不断成长。代码审查是讨论替代方案和与你之前方案不同方法的好方法，还能让你免费汲取他人的知识。

做好代码审查需要时间。我合作过的优秀公司，审查流程确实“耗时”，但这些时间是值得投入的！今天因为“慢”而浪费的时间，很可能在以后的长期代码库建设中，以数量级的速度节省下来！