代码审查的 10 个经验教训

Posted 2022-09-03 飞天程序猿

前年秋天，我的开发团队从 2人增长到 6人。在来自不同背景的多位开发人员共同开发后，正确的拉取请求和代码审查突然变得至关重要，以确保我们拥有一个有凝聚力的代码库。

作为团队的首席开发人员，我是负责进行这些审查的主要人员。以前从未这样做过，我有很多东西要学习如何使这些评论有效。以下是我在过去几个月进行代码审查的经验中学到的#10技巧和经验教训。

​

1.总是从积极的开始

有时，PR 有很多错误：没有使用正确的元素，实现的设计与模型不匹配，逻辑没有意义等等。作为审阅者，你的工作就是寻找这些错误并指出要纠正的错误，很容易只关注那些负面因素。

但是没有人故意犯错误，所以公开指出这些错误可能是一种消极、不舒服的经历。写出所有这些错误对审阅者来说也不好玩。为了树立积极的基调，我学会了总是以感激和我认为他们做得好的事情开始我的评论。即使代码有很多问题需要解决，感谢这个人的贡献也很重要。有错误的代码总比没有代码好，所以感谢他们第一次解决问题。

如果评论中没有提到代码，通常会被认为是好的，但是积极地表扬你会大有帮助。它建立信心并使人们更容易接受反馈，因为他们知道你已经花时间彻底检查他们的代码。如果他们对 X 的逻辑不是那么好，但他们在 Y 和 Z 上做得很好，让他们知道！

2.不是“你”，是“代码”

如果你曾经了解过解决冲突的方法，那么你可能已经了解了“我”陈述的重要性。使用诸如“我认为……”、“我觉得……”之类的短语而不是“你做了……”可以大大缓解紧张情绪，并将焦点从个人转移到问题本身。

同样的方法应该应用于代码审查。提出批评时，重要的是要避免使用“你”这个词。接受对你工作的批评已经很困难了，所以不要让别人觉得是他们错了。例如，切换

你在第 25 行的逻辑不清楚。

至

我不清楚第 25 行的逻辑。

完全改变了评论的语气。而且我知道在审查我的代码时我更愿意阅读哪一个。

3.使用清单项建议

我的团队在我们的大多数项目中都使用 GitHub，我最喜欢的功能之一是能够发表关于特定代码行的评论。它消除了在较大注释中写出特定文件/行号所带来的许多麻烦和潜在的混乱。如果你的大部分评论都是单个更改，这可以帮助你制作一个简单的清单，列出需要进行的修复。

如果你使用不提供此功能的其他平台，那么我强烈建议你在撰写评论时包含/链接到特定的行号。作为审阅者，这对你来说可能需要做更多的工作，但这将有助于确保不会忽视这些必要的更改。

4. 尽早设定项目标准和工具来帮助审查

我们都学习如何并且更喜欢以不同的方式编写代码。当我是唯一的开发人员时，我从来不用担心代码风格、命名约定或其他项目标准之类的事情，因为无论如何我这样做都是“正确”的方式。当我开始审查其他人的代码时，我非常非常迅速地意识到，并非每个人都有与我相同的内部标准，这不仅导致代码库混乱，而且需要大量额外的精力来审查。

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

无论这些标准是什么，重要的是整个团队都参与其中并了解预期的内容。你需要它们来处理一切：正在使用的语言、分支命名约定、项目组织、注释约定等。

旁白：这个过程让我意识到我对 CSS 属性顺序有强烈的看法，所以我在讨论中强调了这一点。

无论你是在内部开发自己的标准还是使用现有的许多标准之一，都取决于你，但如果你想在项目结束时拥有任何类似的内聚代码库，那么这样做至关重要。

​

帮助审查的工具

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

为了捕捉任何进入 PR 的错误（尽管理想情况下，它们首先在本地被捕捉和处理），我们设置了 TravisCI 来运行额外的检查。因此，如果在我进行审查时 Travis 构建失败，它为我提供了一个在深入研究之前开始的地方。

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

一个拉取请求中可能有很多代码，所以就实际进行代码审查而言，我喜欢从广义上开始，然后深入了解细节。对我来说，这个过程通常是这样的：

1. 有没有失败的测试？如果是，他们为什么会失败？
2. PR 中是否包含任何不应该存在的额外文件？
3. 我可以在没有任何错误的情况下切出分支吗？
4. 是否更新了任何相关文档以反映更改？
5. 是否向项目中添加了新的包或依赖项？如果是，为什么要添加它们？他们需要吗？
6. html 是否有效、语义化和可访问？
7. CSS 是否遵循项目标准？实施中是否考虑了所有窗口宽度？跨浏览器兼容性如何？
8. javascript 是否遵循项目标准？是模块化的吗？遵循逻辑容易吗？是否考虑了边缘情况？控制台中是否有杂散日志？

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

6. 建立专门的审查时间

这对我来说是最难学习的课程之一，也是我仍在积极努力的事情。进行彻底和富有成效的代码审查需要时间。即使 PR 很小，它仍然（通常）需要检查分支、检查逻辑、审查问题等。当你有其他竞争优先级时，可能很容易忽略该拉取请求或在以下情况下做最少的事情审查，但这不是一个好的长期解决方案。

我对此的解决方案相当简单：我有专门的时间来做评论。我在我的日历上阻止它，我的团队知道这些时间是什么时候，所以他们知道什么时候可以期待反馈。为你的团队和你自己设定期望是关键。

7.建立你的期望

你是否将你的拉取请求链接到问题？提交拉取请求时需要某种格式？对单个请求中应包含多少行代码有限制？

如果你对这些问题中的任何一个回答是肯定的，那么预先建立这些期望很重要。它可以节省你作为审阅者的时间，并有助于防止你的团队不得不猜测你要查找的内容。花时间与你的团队交谈，找出最适合你们所有人的方法，因为...

8. 大家评论

在我们的团队中，每个人都有机会进行代码审查，每个人的代码都经过审查。作为团队的高级开发人员，我的拉取请求在合并之前会经过其他两个成员的审核。我这样做是因为：

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

我坚信学习如何编写好代码的最佳方法是阅读编写良好的代码，因此即使没有什么可更改的，它也可以让他们阅读与他们的项目相关的优秀代码示例正在努力。我们经常在代码审查中就实现进行良好的对话，当我能够回答有关它们的问题时，这让我对自己的决定更有信心。

9.经常重新评估

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

询问什么有效，什么无效，并诚实回答！询问你的团队成员他们认为哪些反馈有帮助或确定可以改进批评的领域。考虑一下你花了多少时间进行评论并从中识别出任何模式。如果你经常评论相同类型的问题，你是否可以采取一些措施来解决它，以便在下一个项目中减少这些问题？反思这些类型的问题并做出改变将改善团队中每个人的审查过程。

10. 解决方案不止一种

这个很难。真的很难。当你是审阅者时，开始重构提交者的代码以反映你将如何完成它可能非常诱人。最初的简单重构很容易变成将整个代码部分重做为你的“正确”解决方案。但这不是代码审查的目的。

可以肯定的是，这是一条很好的路线。有时代码确实需要重新构想和完全重写，但这不应该经常发生。如果是这样，那么更好的方法是在代码审查阶段之前配对程序。

但仅仅因为这不是你处理和解决问题的方式，并不意味着它不好。当你打开拉取请求并开始审查时，你需要在门口检查你的自我，并以开放的心态考虑新的解决方案。把它当作一个学习的机会，而不是炫耀你认为自己有多聪明。

这是一次学习所有这一切的旅程，我感谢我的团队在我弄明白时一直保持耐心。在持续学习和经常重新评估的本质中，你有哪些进行代码审查的技巧？可以在评论区分享出来，大家一起学习！