改善代码审查沟通的 5 个技巧（第 2 部分）
改善代码审查沟通的 5 个技巧（第 2 部分）
第 1 部分在这里： https://medium.com/@mj.gudenas/3-tips-to-make-your-git-pull-requests-easier-to-review-e76813b1bb5a
在第一部分中，我从作者的角度讨论了代码审查。我认为审稿人也有足够的空间在简化审稿过程中发挥作用。代码审查是一个协作过程，它是团队聚集在一起并构建比每个人个人贡献的总和更大的东西的绝佳机会。
这篇文章的重点不是你应该如何审查代码，而是你应该如何 交流您的建议 .您可以成为一名出色的工程师，拥有最惊人的洞察力，但如果您以错误的方式传达它们，您将很难传达您的信息。审查你的工作可能会有压力，因为每个人都在一定程度上依附于他们的代码，这意味着讨论会变得很激烈。我的目标是帮助您编写与作者合作的代码审查，而不是反对他们。
1.努力做个好人
众所周知，与说出的相同信息相比，书面信息会显得更严厉。这是因为书面文本缺乏语气，而语气是沟通的关键要素。当我们说话时，我们可以用一种愉快的语气以一种不那么咄咄逼人的方式传递我们的信息。您不希望您的信息显得过于批评或对抗，因此您需要使用其他方式使其看起来更友好：
一个。建议更改时避免使用命令式或批判性语言。 命令式语言听起来像是一个指令，而不是一个建议，这会让作者更具防御性。即使你确定有问题，如果你把它听起来像是一个建议，你会发现说服作者会容易得多：
- “不要做X” ⇒ “我们可以避免做 X”
- “把这个改成 X”⇒“我们能不能把它改成 X”
- “这是个坏主意”⇒“我们可以考虑另一种方法吗？”
- “这行不通” ⇒ “我们是否验证了这种方法？”
请注意使用“我们”而不是“您”。这样，信息就从作者转移到整个团队，强调作品的集体所有权，而不是将批评直接放在作者身上。
湾。小心使用表情符号 .虽然有些人喜欢添加表情符号来代替语气，但我认为它并不总是按预期的方式工作。例如，在您的评论中添加微笑可以使其听起来居高临下和滑稽，例如 “这是错误的 ” 如果您真的想使用表情符号，我会坚持使用那些传达更中性情绪的表情符号，例如或。
C。谦虚和同情作者。 不要忘记，无论你对某事有多么确定， 你可能错了。 即使你是对的，你也想以更加谦逊的态度来处理它，让它听起来像是一次讨论，而不是对这种方法的批评。请记住——作者可能在这个 PR 中投入了数天的时间。如果你被认为是一个令人难以忍受的无所不知的人，他们会倾向于为自己的方法辩护。
总体而言，您应该为您的受众量身定制沟通方式。有些人，你可以更直接，他们不会介意。但我总是宁愿过于友善，也不愿冒着冒犯或激怒他人的风险，因为他们的评论很严厉。这在审查团队新人或更年轻的人的代码时尤其重要，因为让他们的工作遭到破坏可能会对他们的士气造成很大打击，他们可能会永远被你吓倒。
2. 明确评论的预期结果
在 PR 上写评论时，你可能会做以下事情之一：
- 称赞一个好主意或一段好代码
- 提出问题——这个问题可能只是您出于兴趣而提出的问题，因为您以前没有见过这种方法，或者您可能要求澄清
- 提出一个小建议
- 提出严重问题（阻止 PR 合并）
明确是哪一个 .如果您的评论被阻止，即 PR 在解决之前无法合并，请明确说明。如果您留下了多条评论，然后“请求更改”，作者可能会认为您的所有评论都被屏蔽了，尽管它可能只是其中之一。
这是另一个例子——假设你审查了一个 PR，但不批准它或请求更改，但留下一条建议进行小重构的评论。作者不确定您是否希望在他们获得您的批准之前解决该评论。您可以通过清楚地将您的评论标记为“次要”或“建议”来使其明确。
如果您没有阻止评论并且只有小建议，您应该批准 PR 并将其留给作者来决定他们是否要实施您的建议。 不要通过不批准 PR 来迫使人们接受你的建议，也不要推迟批准其他工程师，特别是如果你是高级和权威的工程师。 其他人可能不愿意批准有您的评论但没有批准的 PR。
3.在发表评论之前完成您的评论
在发表评论之前，请确保您快速浏览 PR 并估计您需要多长时间才能进行评论。 如果您没有时间完整地审查 PR，甚至不要开始审查它。 从作者的角度来看，在处理完评论反馈后收到第二批评论是非常烦人的。有时这是不可避免的，因为作者在处理最初的评论时可能会在代码中引入额外的问题。但是，对 PR 进行部分审查，留下一些评论，然后稍后再回来添加更多评论，这对作者来说很烦人且效率低下。
您可能认为最好留下一些评论，然后让作者在您查看 PR 的其余部分时解决这些评论。但是，您必须记住，在 GitHub 上 PR 是按照受影响文件在文件系统中出现的顺序显示的。 您稍后可能会发表与您刚刚评论的代码直接相关的评论，因此会导致重复的，有时甚至是相互矛盾的建议 .
如果您将其他人的评论添加到混合中，作者可能很难理解这一切。最好先完整审查 PR，然后一次性发布所有评论——GitHub 允许你这样做。
Use “Start a review” instead of “Add single comment” to publish your comment at the end of your review.
最后，上下文切换非常低效。如果你回顾了 PR 的一部分，然后稍后再回来，你可能需要再看一遍之前回顾的部分来记住上下文。
4.不要打死马
我们都看过让我们想哭的 PR，我们可能在上面留下了几十条评论。但是，我认为这不一定是这种情况下的最佳方法。首先， 对于作者和审稿人来说，处理大量评论可能会让人不知所措。 我已经看到评论的数量增长到了一百多个，尤其是在作者为他们的作品辩护并且许多评论发展成全面讨论的情况下。
在审查 PR 时，试着思考是否值得花时间一一解决所有问题。 为你的作品收到很多批评是很丢脸的，所以在发表严厉的评论之前，考虑私下联系作者并与他们讨论。 PR不达标的原因可能有很多。例如，作者可能是代码库（或公司）的新手，并且被分配了对他们来说太复杂的工作。与其留下数十条评论，不如与作者配对并帮助他们学习。很有可能，无论如何，这对你来说可能比写下所有的评论要快，你的努力肯定会得到作者的赞赏。我可以根据经验说，人们会记得你在未来几年帮助过他们。
5.包括积极和好奇的评论
公关审查的目的不仅仅是批评其他人的工作。这也是大家互相学习的机会。友善不花钱，但可以真正对作者产生影响，特别是如果评论已经有很多建设性的评论。称赞一段聪明的代码，特别是如果它是你以前从未见过的新模式。您可以向作者询问有关该模式的更多信息，以便了解更多信息。
请记住，公关审查与同行绩效审查非常相似，适用相同的原则。作者更有可能对更平衡的评论做出积极回应，而不是对其作品的严厉批评。
代码审查不是一门精确的科学。您在评论中的沟通方式将取决于您所在的团队。但是，我认为一般原则将适用于大多数场景，并使您的代码审查更加可口：
- 对人好点
- 沟通清楚
- 务实
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
