v0.57

代码审查

代码审查的总体目标是作为我们团队其他人的安全网，帮助他们编写更好的代码，而不是评判他们或他们的代码。如有疑问，请假设他们是出于好意，并且保持友好。

目标

作为审查员，你的首要目标是充当安全网，防止坏代码被合并。 “坏”的定义是高度主观的、依赖于上下文的，并且会随着产品时间和成熟度而变化。

当你发现明显的错误时，花时间说明为什么你认为它们是错误。

如果你看到不同意某种方法的地方，请说出来。但是，也要花时间去理解作者为什么做出了某个选择。你应该假设作者根据当时所知做出了一个好的决定。你可能拥有不同的知识集合，并且看到不同的结果。深入研究这些。他们可能会看到你没看到的东西，反之亦然。

寻找可以借鉴的技巧、技术或惯用法。你的同事都是聪明人。很有可能他们有一些你可以学习的技巧。一定要让他们知道。

审查员是在帮你。他们是为了帮助你做到最好。最优秀的人都有教练、编辑和导师。你的代码审查员也应该以同样的方式帮助你。在他们更有经验的情况下，这可以是直接的指导。在他们更初级的情况下，他们拥有一双新鲜的眼睛，可能会让你质疑根深蒂固的假设。

当审查员不同意你采取的方法时，请努力理解原因。他们可能知道你不知道的事情或看到你没看到的结果。虽然他们可能没有像你一样深入地思考 PR 的具体主题，但他们同样可能正在考虑 PR 对你可能不关注的领域的影响。

如果有人对你的 PR 强行给出 :-1:，请格外耐心。深入了解他们为什么认为 PR 有缺陷。以改进 PR 为目标来开始对话，而不是为你的方法辩护。在辩论中做得更好不会给你加分，但在交付更好的代码和更好的产品方面你会获得加分，无论灵感或想法来自哪里。

请注意，这些 :+1:、:+0: 和 :-1: 应该明确地在评论中说明，而不是作为 GitHub 上 PR 主要描述的反应。从 :-1: 变为 :+1: 也应在评论中明确说明。

高优先级问题的 PR 应尽快进行代码审查。
里程碑问题的 PR 可以等待几天。
如果 PR 上没有 :+1:，则 PR 创建者有责任跟进其他人并获得代码审查。重申一下，PR 需要 :+1: 才能合并，如果尚未审查，则由 PR 的发起者负责寻找审查者。
如果存在 :-1: 且没有明确的解决方案，PR 创建者和投 :-1: 的人应计划在接下来的几天里花一个小时来讨论问题，并计划如何解决它。
如果 PR 在一周后仍未有任何进展且有 :-1:，@salsakran 将介入。