为您的团队带来健康的代码审查心态

“代码审查”是开发过程中的一个时刻，您（作为开发人员）和您的同事一起工作，并在最近的一段代码发布之前寻找错误。 在这样的时刻，您可以是代码作者或审阅者之一。

在进行代码审查时，您可能不确定要查找的内容。 另一方面，在提交代码审查时，您可能不知道要等待什么。 双方缺乏同理心和错误的期望可能会引发不幸的情况，并匆忙推进这一进程，直到双方都经历不愉快。

在本文中，我将分享如何通过在代码审查期间改变思维方式来改变这一结果：

• 作为一个团队
• 作为作者
• 作为审稿人

团队合作

培养合作文化

在我们开始之前，了解为什么需要审查代码的价值至关重要。 知识共享和团队凝聚力对每个人都有好处，但是，如果以糟糕的心态完成代码审查，代码审查可能会耗费大量时间并产生不愉快的结果。

团队的态度和行为应该包含非判断性协作的价值，以学习和分享为共同目标——无论其他人的经验如何。

在您的估计中包括代码审查

完整的代码审查需要时间。 如果更改需要一周时间，不要期望代码审查不到一天。 它只是不能那样工作。 不要急于进行代码审查，也不要将其视为瓶颈。

代码审查与编写实际代码一样重要。 作为一个团队，请记住在您的工作流程中包含代码审查，并设定对代码审查可能需要多长时间的预期，这样每个人都会同步并对他们的工作充满信心。

通过指南和自动化节省时间

保证一致贡献的一种有效方法是在项目中集成一个 Pull Request 模板。 这将有助于作者提交一份完整描述的健康 PR。 PR 描述应该解释改变的目的是什么，背后的原因，以及如何重现它。 屏幕截图和参考链接（Git 问题、设计文件等）是不言自明的提交的最后润色。

这样做可以防止审阅者提前发表评论，询问更多细节。 另一种让代码审查看起来不那么挑剔的方法是在审查者参与之前使用 linter 来发现代码格式和代码质量问题。 每当您在审核过程中看到重复的评论时，请寻找将其最小化的方法（使用更好的指南或代码自动化）。

留个学生

任何人都可以进行代码审查，并且每个人都必须接受代码审查——无论资历级别如何。 感激地接受任何反馈，以此作为学习和分享知识的机会。 将任何反馈视为公开讨论，而不是防御性反应。 正如瑞安假日所说：

“业余爱好者是防守型的。 专业人士发现学习（甚至偶尔出现）是令人愉快的； 他们喜欢接受挑战和谦卑，并把教育作为一个持续不断的过程。 （……）”

——瑞恩·霍利迪，自我是敌人

保持谦虚，因为一旦你不再是学生，你的知识就会变得脆弱。

选择审稿人的艺术

在我看来，挑选审阅者是团队进行有效和健康的代码审查最重要的决定之一。

假设您的同事正在提交代码审查并决定标记“每个人”，因为不知不觉中，她/他可能希望加快流程，提供可能的最佳代码或确保每个人都知道代码更改。 每个审阅者都会收到通知，然后打开 PR 链接，看到很多人被标记为审阅者。 “别人会做”的想法突然出现在他们的脑海中，导致忽略代码审查并关闭链接。

由于还没有人开始审稿，你的同事会提醒每一位审稿人去做，即给他们施加压力。 一旦审稿人开始这样做，审稿过程就会永远持续下去，因为每个人都有自己的意见，而达成共识是一场噩梦。 同时，无论谁决定不审查代码，都会收到大量包含所有审查评论的电子邮件通知，从而影响他们的工作效率。

这是我看到的比我想的更多的事情：拉取请求，一群人被标记为审阅者，具有讽刺意味的是，在非生产性代码审查中结束。

在选择审阅者时，有一些常见的有效流程： 一个可能的流程是挑选两到三个熟悉代码的同事，请他们担任审阅者。 Gitlab 团队解释的另一种方法是采用链式审阅流程，其中作者选择一个审阅者，然后再选择另一个审阅者，直到至少有两个审阅者同意代码。 无论您选择哪种流程，都要避免过多的审阅者。 能够信任同事对代码的判断是进行有效且健康的代码审查的关键。

有同理心

发现要改进的代码片段只是成功的代码审查的一部分。 同样重要的是通过对同事表现出同理心来以健康的方式传达反馈。

在撰写评论之前，请记住设身处地为他人着想。 写的时候很容易被误解，所以在发送之前检查你自己的话。 即使谈话开始变得丑陋，也不要让它影响到你——始终保持尊重。 对别人说好话从来都不是一个糟糕的决定。

知道如何妥协

当讨论没有迅速解决时，将其带到个人电话或聊天中。 一起分析它是否是一个值得让当前变更请求瘫痪的主题，或者它是否可以在另一个主题中解决。

灵活但务实，知道如何平衡效率（交付）和有效性（质量）。 作为一个团队做出妥协是一种妥协。 在这些时刻，我喜欢将代码审查视为一次迭代，而不是最终解决方案。 下一轮总是有改进的余地。

面对面的代码审查

以结对编程风格将作者和审阅者聚集在一起可能非常有效。 就个人而言，当代码审查涉及复杂的更改或有大量知识共享的机会时，我更喜欢这种方法。 尽管这是一次离线代码审查，但对所进行的讨论留下在线评论是一个好习惯，尤其是在会议结束后需要进行更改时。 这对于让其他在线评论者保持最新也很有用。

从代码审查结果中学习

当代码审查经历了很多更改、花费了太长时间或已经进行了太多讨论时，请将您的团队聚集在一起并分析原因以及可以从中采取哪些措施。 当代码审查很复杂时，将未来的任务拆分成更小的任务会使每次代码审查变得更容易。

当经验差距很大时，采用结对编程是一种具有令人难以置信的结果的策略——不仅用于知识共享，还用于离线协作和交流。 无论结果如何，始终以具有明确期望的健康充满活力的团队为目标。

作为作者

作为作者进行代码审查时，主要关注的一个问题是在第一次阅读代码时尽量减少审查者的惊讶。 这是进行可预测且流畅的代码审查的第一步。 这是你如何做到的。

建立早期沟通

在编码过多之前与您未来的审阅者交谈绝不是一个坏主意。 无论是内部还是外部贡献，您都可以在开发开始时一起进行改进或一些结对编程来讨论解决方案。

作为第一步寻求帮助并没有错。 事实上，在审查之外合作是防止早期错误和保证初步协议的第一个重要步骤。 同时，您的审阅者会知道将来要进行的代码审查。

遵循指南

在提交要审核的拉取请求时，请记住添加描述并遵循指南。 这将节省审阅者花时间了解新代码的上下文。 即使您的审稿人已经知道它是关于什么的，您也可以借此机会提高您的写作和沟通技巧。

成为您的第一位审稿人

在不同的上下文中查看您自己的代码可以让您找到您在代码编辑器中遗漏的内容。 在询问您的同事之前，对您自己的代码进行代码审查。 有审阅者的心态，真正地检查每一行代码。

就个人而言，我喜欢注释我自己的代码审查，以更好地指导我的审查者。 这里的目标是防止与可能缺乏关注有关的评论，并确保您遵循贡献指南。 旨在提交代码审查，就像您希望收到的一样。

耐心点

提交代码审查后，不要直接跳到一条新的私人消息中，要求您的审查者“看看，只需要几分钟”并间接渴望那个竖起大拇指的表情符号。 试图催促你的同事完成他们的工作并不是一种健康的心态。 相反，请相信你同事的工作流程，因为他们相信你会提交一份好的代码审查。 同时，等待他们有空时与您联系。 不要将您的评论者视为瓶颈。 记住要有耐心，因为困难的事情需要时间。

做一个倾听者

一旦提交了代码审查，就会出现评论，提出问题并提出更改。 这里的黄金法则是不要将任何反馈视为人身攻击。 请记住，任何代码都可以从外部角度受益。

不要将您的评论者视为敌人。 相反，请利用这一刻放下自我，接受自己犯的错误，并愿意向同事学习，以便下次可以做得更好。

作为审稿人

提前计划

当你被要求成为审稿人时，不要马上打断事情。 这是我经常看到的一个常见错误。 审查代码需要您全神贯注，每次切换代码上下文时，您都会浪费时间重新调整注意力，从而降低工作效率。 相反，通过分配一天中的时间段来进行代码审查来提前计划。

就个人而言，我更喜欢在早上或午餐后在选择任何其他任务之前先进行代码审查。 这对我来说最有效，因为我的大脑仍然很新鲜，没有以前的代码上下文可以关闭。 除此之外，一旦我完成了审查，我可以专注于自己的任务，而作者可以根据反馈重新评估代码。

给予支持

当拉取请求不遵循贡献指南时，请给予支持——尤其是对新手。 以此为契机，指导作者改进他/她的贡献。 同时，试着理解为什么作者一开始就没有遵循这些指导方针。 也许还有一些你以前不知道的改进空间。

检查分支并运行它

在审查代码时，让它在您自己的计算机上运行——尤其是当它涉及用户界面时。 这个习惯将帮助您更好地理解新代码并发现如果您只是在浏览器中使用默认的 diff-tool 可能会错过的东西，这将您的审查范围限制在更改的代码（没有代码编辑器中的完整上下文） .

假设前询问

当你不明白某事时，不要害怕说出来并提出问题。 询问时，请记住先阅读周围的代码，避免做出假设。

大多数问题都属于这两种类型：

1. “如何”问题
   当你不明白某件事是如何工作的或它做了什么时，如果代码足够清晰，请与作者一起评估。 不要把简单的代码误认为是无知。 难读的代码和你不知道的代码是有区别的。 乐于学习和使用新的语言功能，即使您还没有深入了解它。 但是，仅当它简化了代码库时才使用它。
2. “为什么”问题
   当你不明白“为什么”时，不要害怕建议对代码进行注释，尤其是在它是边缘情况或错误修复的情况下。 在解释它的作用时，代码应该是不言自明的。 评论是对解释某种方法背后的原因的补充。 就可维护性而言，解释上下文非常有价值，它可以避免人们删除认为无用的代码块。 （就个人而言，我喜欢对代码进行评论，直到我觉得以后可以放心地忘记它为止。）

建设性的批评

一旦你找到一段你认为应该改进的代码，永远记得要承认作者为项目做出贡献的努力，并以一种接受和透明的方式表达自己。

• 公开讨论。
  避免将您的反馈形式化为命令或指责，例如“您应该……”或“您忘记了……”。 将您的反馈表达为公开讨论，而不是强制性要求。 记得评论代码，而不是作者。 如果评论不是关于代码的，那么它不应该属于代码审查。 如前所述，支持。 使用被动语态、以复数形式交谈、表达问题或建议是强调与作者同理心的好方法。
  

而不是“从这里提取这个方法……”更喜欢“应该提取这个方法……”或“你觉得提取这个方法怎么样……”

• 清楚。
  反馈很容易被误解，尤其是在表达意见与分享事实或指导方针时。 永远记得在你的评论中立即清除。

不清楚：“这段代码应该是……”

意见：“我相信这段代码应该是……”

事实：“按照 [我们的指导方针]，这段代码应该是……”。

• 解释为什么。
  对你来说很明显的东西，可能对其他人来说并不明显。 它永远不会过多地解释您的反馈背后的动机，因此作者不仅了解如何更改某些内容，而且了解它的好处是什么。

意见：“我相信这段代码可能是……”

解释：“我相信这段代码可能是（……），因为这将提高可读性并简化单元测试。”

• 提供例子。
  在分享作者不熟悉的代码功能或模式时，请以参考作为指导来补充您的建议。 如果可能，请超越 MDN 文档并分享适用于当前代码场景的片段或工作示例。 如果编写的示例过于复杂，请给予支持，并亲自或通过视频通话提供帮助。

除了说诸如“使用过滤器将帮助我们[动机]”之类的话，还要说，“在这种情况下，它可能是这样的：[代码片段]。 您可以查看 [Finder.js 中的示例]。 如有任何疑问，请随时在 Slack 上联系我。”

• 讲道理。
  如果多次出现相同的错误，最好只留下一条评论，并记住作者在其他地方也对其进行审查。 添加多余的注释只会产生噪音，并且可能会适得其反。

保持焦点

避免提出与当前代码无关的代码更改。 在提出改变建议之前，问问自己当时是否绝对有必要。 这种类型的反馈在重构中尤其常见。 这是我们作为一个团队需要在效率和有效性之间做出的众多权衡之一。

当谈到重构时，就个人而言，我更倾向于小而有效的改进。 这些更容易审查，并且在使用目标分支更新分支时发生代码冲突的可能性较小。

设定期望

如果您将代码审查半途而废，请让作者知道，这样时间预期就会受到控制。 最后，还要让作者知道您是否同意新代码，或者您是否想稍后再重新审查它。

在批准代码审查之前，问问自己是否对将来接触该代码的可能性感到满意。 如果是，这表明您进行了成功的代码审查！

学会拒绝代码审查

尽管没有人承认这一点，但有时您不得不拒绝代码审查。 当您决定接受代码审查但试图匆忙进行时，项目的质量以及您团队的心态都会受到影响。

当你接受审查别人的代码时，那个人就信任你的能力——这是一种承诺。 如果您没有时间成为审稿人，请对您的同事说不。 我真心的; 不要让您的同事等待永远不会完成的代码审查。 记得沟通并保持明确的期望。 对你的团队诚实，甚至对你自己诚实。 无论您选择什么，都要健康地做，并且做对。

结论

如果有足够的时间和经验，进行代码审查将教给您的不仅仅是技术知识。 您将学会给予和接受他人的反馈，并在做出决定时投入更多思考。

每次代码审查都是作为一个社区和个人成长的机会。 即使在代码审查之外，也要记住培养一种健康的心态，直到有一天它对你和你的同事来说自然而然。 因为分享让我们变得更好！

关于 SmashingMag 的进一步阅读：

• 一起工作：设计师和开发人员如何沟通以创建更好的项目
• 通过将设计师带入代码审查过程来更好地协作
• 网页设计师和开发人员应该听哪些播客？
• 如何制作完美的 Web 开发人员简历