代码审查的 10 个经验教训

去年秋天，我的开发团队从 1 人（我）扩大到 3 人。在来自不同背景的多名开发人员共同努力之后，适当的拉取请求和代码审查突然变得至关重要，以确保我们拥有一个具有凝聚力的代码库。

作为团队的首席开发人员，我是负责进行这些代码审查的主要人员。由于之前从未做过这件事，我有很多东西需要学习，才能确保这些审查有效。以下是我在过去几个月进行代码审查的经验中总结出的10条技巧和经验教训。

1. 始终以积极的态度开始

有时，PR 会有很多错误：没有使用正确的元素、实施的设计与模型不匹配、逻辑不合理等。作为审阅者，你的工作是寻找这类错误并指出它们以进行纠正，并且很容易只关注那些负面的东西。

但没有人会故意犯错，所以公开指出这些错误可能会是一种负面且令人不快的经历。把所有这些错误都写出来对审阅者来说也不是什么愉快的经历。为了营造积极的氛围，我学会了在审阅的开头总是表达感激之情，并指出我认为他们做得好的地方。即使代码中有很多问题需要解决，也必须感谢他们的贡献。有错误的代码总比没有代码好，所以感谢他们花了第一时间解决问题。

如果代码在评论中没有被提及，通常被认为是好的，但积极地给予赞扬会大有帮助。这能建立信心，让人们更容易接受反馈，因为他们知道你花时间彻底检查了他们的代码。如果他们在 X 部分的逻辑不太好，但 Y 和 Z 部分做得很好，请告诉他们！

2. 关键不在于“你”，而在于“代码”

如果你学过如何化解冲突，你可能已经了解了“我”型陈述的重要性。用“我认为……”“我感觉……”这样的表达方式来代替“你做了……”，可以极大地缓解紧张局势，并将焦点从个人转移到问题本身。

同样的方法也适用于代码审查。提出批评时，务必避免使用“你”这个词。接受对你工作的批评本身就很困难，所以不要让对方觉得是他们自己错了，从而加剧这种困难。例如，切换

第 25 行的逻辑不清楚。

到

我不太明白第 25 行的逻辑。

彻底改变了评论的语气。而且我知道当我的代码被审查时，我更愿意读哪一条。

3. 使用订单项建议

我的团队在大多数项目中都使用 GitHub，我最喜欢的功能之一就是能够针对特定代码行发表评论。这省去了在长评论中写出具体文件/行号所带来的很多麻烦和潜在的困惑。如果大多数评论都是单项修改，这可以帮助你制作一个简单的需要修复的清单。

额外福利：GitHub 提供项目建议。详情请参阅@_darrenburns 的 “8 个 GitHub 生产力技巧” 。

如果您使用的其他平台不提供此功能，我强烈建议您在撰写评论时添加/链接到具体的行号。这可能会增加您作为评论者的工作量，但这有助于确保那些必要的更改不会被忽略。

4. 尽早设定项目标准并设置工具以帮助审查

我们每个人都会学习如何以不同的方式编写代码，并且都喜欢这样做。当我独自开发代码时，我从来不用担心代码风格、命名规范或其他项目标准，因为无论我怎么做，都是“正确”的方式。但当我开始审查其他人的代码时，我很快意识到，并非每个人都和我拥有相同的内部标准，这不仅会导致代码库混乱，还会耗费我大量的额外精力去审查。

这里学到的教训很简单：尽早设定项目标准。

无论这些标准是什么，重要的是整个团队都要遵守，并且了解预期。而且，所有事情都需要它们：使用的语言、分支命名规范、项目组织、注释规范等等。

附言：这个过程让我意识到我对 CSS 属性顺序有强烈的意见，所以我在讨论中特意解决了这个问题。

您是内部开发自己的标准还是使用现有的众多标准之一都取决于您，但如果您希望在项目结束时拥有一个具有凝聚力的代码库，那么这样做至关重要。

帮助审查的工具

一旦你有了项目标准，就值得花时间设置专门用于帮助执行这些标准的工具。你可以使用 Linter 来分析你的代码，并将其与一组语法相关标准的指南进行比较。它会标记任何错误，甚至可能自动为你修复。

为了捕获 PR 中出现的任何错误（尽管理想情况下，这些错误会先在本地捕获并处理），我们设置了 TravisCI 来运行额外的检查。这样，如果我在审核时 Travis 构建失败了，它就能让我在深入研究之前有一个初步的了解。

5. 从广泛入手，然后深入细节

单个拉取请求中可能包含大量代码，因此在实际进行代码审查时，我喜欢先从大处着手，然后再逐步深入细节。对我来说，这个过程通常是这样的：

1. 有没有失败的测试？如果有，为什么失败？
2. PR 中是否包含不应该存在的额外文件？
3. 我可以毫无错误地检出分支吗？
4. 是否有任何相关文档更新以反映这些变化？
5. 项目中是否添加了新的包或依赖项？如果是，为什么要添加它们？它们是必需的吗？
6. HTML 是否有效、语义化且可访问？
7. CSS 是否遵循项目标准？实现时是否考虑了所有视口宽度？跨浏览器兼容性如何？
8. JavaScript 代码是否遵循项目标准？它是模块化的吗？逻辑是否易于理解？是否考虑了边缘情况？控制台中是否有杂散的日志？

如果在前几个步骤中出现很多问题，我通常会在那里结束审查，等待这些问题得到解决，然后再深入研究代码中更密集的部分。

6. 设立专门的复习时间

这是我学到的最难的教训之一，至今仍在努力克服。进行彻底且高效的代码审查需要时间。即使 PR 很小，它通常仍然需要检出分支、检查逻辑、审查问题等等。当你有其他优先事项时，你可能会倾向于忽略该 PR 或在审查时只做最基本的工作，但这并非长久之计。

我的解决方案很简单：我会专门安排一个时间来做评审。我会把它标记在日历上，这样我的团队就知道这些时间是什么时候，这样他们就知道什么时候能收到反馈。为你的团队和你自己设定期望值是关键。

7. 明确你的期望

你的拉取请求会链接到问题吗？提交拉取请求时需要遵循特定格式吗？单个请求中包含的代码行数有限制吗？

如果您对以上任何一个问题的回答是肯定的，那么提前明确这些期望就很重要了。这可以节省您作为审核员的时间，并避免您的团队猜测您正在寻找什么。花点时间与您的团队沟通，找出最适合你们所有人的方法，因为……

8. 每个人都评论

在我们团队，每个人都有机会进行代码审查，并且每个人的代码都会被审查。作为团队的高级开发人员，我的拉取请求需要经过另外两位成员的审核才能合并。我这样做是因为：

1. 我的代码有错误，但通常可以改进，
2. 它为初级开发人员创造了空间来询问我如何/为什么以我的方式实现某些事情。

我坚信，学习优秀代码的最佳方法是阅读写得好的代码。即使代码本身无需修改，也能让他们阅读到与他们正在进行的项目相关的优秀代码示例。在代码评审中，我们经常就代码实现进行有益的讨论，当我能够回答相关问题时，我对自己的决策更有信心。

9.经常重新评估

对我和我们团队来说，进行代码审查都是一次重要的学习过程。我们根据经验在此过程中做出了很多调整。抽出时间来反思项目的这一方面非常重要；我通常会将其作为项目更广泛的事后分析的一部分，这有助于巩固代码审查作为开发流程中关键环节的地位。

询问哪些方面做得好，哪些方面做得不好，并诚实地回答！询问你的团队成员他们认为哪些反馈有用，或者找出哪些地方可以改进。思考一下你花了多少时间进行评审，并从中找出一些规律。如果你经常评论同一类型的问题，有什么措施可以解决这个问题，以便在下一个项目中减少此类问题？反思这些问题并做出改变，将改善团队中每个人的评审流程。

10. 解决方案不止一个

这个问题很难，真的很难。当你是代码审查者时，你可能会忍不住去重构提交者的代码，以反映出你原本会怎么做。一开始只是简单的重构，但很容易演变成把整段代码都重写成“正确”的解决方案。但这并不是代码审查的目的。

当然，这需要把握一个微妙的界限。有时代码确实需要重新构思和完全重写，但这种情况不应该经常发生。如果确实如此，那么更好的方法是在代码审查阶段之前进行结对编程。

但即使它不是你原本会处理和解决问题的方式，也不意味着它不好。当你打开拉取请求并开始审核时，你需要放下自负，保持开放的心态，考虑新的解决方案。把它当作一个学习的机会，而不是炫耀你自以为有多聪明。

额外奖励：@maxwell_dev在“这与你无关”上发表了一篇精彩的文章来解决这个问题。

学习这些真是一段旅程，我非常感谢我的团队在我摸索的过程中一直给予我耐心。考虑到持续学习和经常重新评估（#9！）的本质，您对于代码审查有什么建议吗？