代码审查¶

在将代码添加到 Mozilla 的代码库之前，需要进行审查。此外，与您在其他开源项目中可能看到的情况相反，代码不会直接推送到代码库。相反，一旦代码获得审查人员的批准，他们将请求将代码合并到代码库中。

所有这些都可以以某种方式手动完成，但我们已经建立了基础设施来帮助我们进行代码审查和代码合并。

了解如何开始对您的代码进行审查和合并，请参阅我们的设置指南。

并继续阅读以了解我们为什么要进行代码审查以及如何进行代码审查。

为什么要进行代码审查？¶

质量¶

进行代码审查有助于确保正确性。它使我们有机会检查代码

是否解决了问题，
是否没有 Bug，
是否没有导致其他问题发生倒退，
是否涵盖了边缘情况。

审查也是审查人员检查是否存在正确的测试覆盖率、更改是否没有性能问题、是否简化了难以理解的代码以及是否附带代码注释和足够的文档的机会。

维护¶

进行审查使我们有机会检查我们是否愿意维护和支持为功能或 Bug 修复引入的新代码。

代码一致性¶

这也是一个很好的机会，让我们检查正在编写的任何新代码是否与代码库中已有的代码一致。

共同责任¶

批准代码审查意味着您是第二个认为此更改正确且是一个好主意的人。这样做使您与作者一样对代码更改负责。

整个 DevTools 团队拥有代码，而不仅仅是作者。我们作为一个团队编写代码，而不是个人编写代码，因为从长远来看，团队负责维护它。

进行审查讨论可以共享代码的所有权，因为作者和审查人员都在其中投入了一点自己的东西，并且产生的代码不仅仅是一个人工作的结果。

代码审查中应该避免什么？¶

理想情况下，应该由代码风格检查工具处理的风格问题。
超出 Bug 范围的要求。

代码审查的一些最佳实践是什么？¶

使用同理心语言。¶

更多阅读

优先使用较小的提交而不是大型的单体提交。¶

这使得审查人员更容易提供高质量的审查。如果更改很小，也更容易达成共识。最后，更容易理解风险并发现回归。

明确表达¶

具体来说，明确区分必需更改和可选更改。

审查是对话，被审查人员应该能够在进行更改之前舒适地讨论和反对更改。

快速响应¶

作为审查人员，尽量在几天内回复，或者至少在一周内回复。

如果无法做到这一点，请更新 Bug 以告知请求者您将在何时进行审查。或者将其转发给有更多时间的人。

寻求帮助¶

知道何时超出您的舒适区作为审查人员，不要犹豫向其他人寻求额外的审查。

没关系，您不可能无所不知，参与的人越多，每个人学到的东西就越多，我们避免的 Bug 就越多。

我们如何沟通？¶

首先，就像在任何 Mozilla 运营的平台或活动中一样，请遵守社区参与指南。

维护人员应通过他们的语气和语言树立榜样。我们希望建立一个包容和安全的环境，以便大家一起工作。

作为审查人员，仔细检查您的评论。仅仅因为您是审查人员并且认为您有更好的解决方案并不意味着这是真的。假设代码作者比您花更多的时间思考代码的这部分（如果您是审查人员），并且实际上可能是正确的，即使您最初认为某些内容是错误的。查找代码并仔细检查不需要花费很长时间。

包容性非常重要。我们不应对请求审查的人或您请求审查的人做出任何假设，并且始终以尽可能包容的方式提供所需的所有信息。

Bug 将永远保存在网上，许多人在作者和审查人员完成工作很久之后都会阅读它。

通过视频/IRC/Slack 交流是获得认可和共享解决方案责任的好方法。它还有助于在更轻松的环境中解决分歧和解决问题。

不要批评被审查人员，只谈论代码本身的质量，而不是直接谈论被审查人员如何编写代码。

花时间感谢并指出良好的代码更改。

使用“请”和“您觉得怎么样？”可以在很大程度上使他人感觉像是同事，而不是下属。