v0.53

代码审查

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

目标

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

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

如果您看到您不同意某种方法的地方，请说出来。但是，也要花时间了解作者做出特定选择的原因。您应该假设作者根据他们当时所知道的情况做出了正确的决定。您可能拥有不同的知识集并看到不同的结果。深入研究这些。他们可能会看到您看不到的东西，反之亦然。

寻找您可以借鉴的技巧、技术或习惯用法。您的队友都很聪明。他们很可能掌握了您可以学习的技巧。让他们知道这一点。

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

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

如果有人在您的 PR 上强烈地给出 :-1:，请特别耐心。深入研究他们为什么认为 PR 有缺陷。以改进 PR 而不是捍卫您的方法的态度进行对话。作为更好的辩论者您不会获得任何积分，但无论灵感或想法来自何处，您都会因交付更好的代码和更好的产品而获得积分。

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

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