v0.56

代码审查

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

目标

作为审查员，您的主要目标是充当安全网，防止不良代码被合并。“不良”的定义高度主观，取决于上下文，并将随着产品时间和成熟度而变化。

当您发现明显的错误时，花时间记录您认为它们是错误的原因。

如果您发现不认同某种方法的地方，请提出。但是，也要花时间了解作者做出特定选择的原因。您应该假设作者是基于他们当时所了解的情况做出了一个好的决定。您可能拥有不同的知识集，并看到不同的结果。深入探讨这些。他们可能看到您没有看到的东西，反之亦然。

寻找您可以借鉴的技巧、技术或惯用语。您的队友都很聪明。他们很可能有您可以学习的技巧。务必让他们知道。

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

当审查员不同意您采用的方法时，请努力理解原因。他们可能知道您不知道的事情或看到您未曾预料到的后果。虽然他们可能没有像您那样深入思考 PR 的具体主题，但他们同样可能在思考 PR 对您可能没有注意到的领域的影响。

如果有人对您的 PR 给予强烈的 :-1:，请特别耐心。深入探讨他们认为 PR 有缺陷的原因。以改进 PR 而非捍卫您的方法为意图来展开对话。您不会因为辩论能力更强而得分，但您会因为发布更好的代码和更好的产品而得分，无论灵感或想法来自何处。

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

高优先级问题的 PR 应在可用后立即进行代码审查。
里程碑中的问题的 PR 可以等几天。
如果 PR 没有 :+1:，则 PR 创建者有责任与其他人跟进并获取其代码的审查。重申一下，PR 需要 :+1: 才能合并，如果尚未审查，则由 PR 的发起者召集审查员。
如果存在 :-1: 且没有明确的解决方案，则 PR 创建者和 :-1: 投票者都应计划在未来一两天内花一小时讨论问题，并计划如何解决它。
如果带有 :-1: 的 PR 在一周后没有进展，@salsakran 将介入。