更好的代码审查实践

代码审查是开发流程的一部分，开发人员与其同事协同工作，查找即将发布的代码中的错误。此时，您可以是代码开发人员，也可以是审查者之一。

在此过程中，一方面，您可能不确定自己想要什么。另一方面，在提交代码审查时，您可能不知道会发生什么。双方之间缺乏同理心和错误的期望可能会引发一些不愉快的情况，并使整个过程仓促进行，最终导致双方都不愉快的体验。

代码审查是提升代码质量、建立最佳实践以及传播经验和知识的有效手段。它还能让开发者向同行学习、进行导师指导，并就他们的构建内容进行开放式对话和讨论。

然而，如果操作不当，代码审查可能会毫无成效，甚至损害团队的人际关系。因此，关注代码审查中的人为因素至关重要。为了获得最佳效果，代码审查需要特定的思维方式和措辞。

以下是我的组织方式：

1. 我的代码审查经历。
2. 通用代码审查指南。
3. 作为开发人员进行代码审查。
4. 作为审阅者进行代码审阅。
5. 谁应该审查？
6. 积极的代码审查文化
7. 代码审查的潜意识影响

我的经历...

最终用户代码审查（无流程）

我记得刚开始做开发者的时候，根本没有代码审查流程。事实上，我收到的唯一一次审查，就是客户报告了某个代码运行不正常的问题，然后发了一条通知。我很快就发现，console.log 在早期版本的 IE 上会造成一些严重的问题。

大家都盯着我看（每周目标练习）

从此，我们团队开始了一个非正式的每周流程：挤在老板的办公室里，拿出一些代码进行审查。这真是一个痛苦的过程……不得不当场在整个开发团队面前解释设计决策；更糟糕的是，还要用我不太熟悉的语言，试图提出一些关于代码的聪明问题。

每个人都评论（学会接受批评）

我之前合作的团队有一个审核流程，它嵌入到提交和推送到生产环境的流程中。默认情况下，团队中的每个人都会参与到这个流程中。Gerrit 中的工具实际上让这个过程变得非常简单直观；事实上，我们能够将一个小组加入到 Gerrit 中，从而简化添加审核人员的流程。

最初几次推送我的代码时，代码审查非常痛苦（不知道会发生什么）......我坚信，我学到的关于代码审查的知识几乎和我为项目本身生成代码的知识一样多。

一个人怎么能如此擅长这个？

我们团队里有一位非常出色的代码审查员，他不仅对代码提出了独到的见解，而且处理起来也非常轻松。正是由于这次互动，我才花时间研究如何复制这种工作（轻松的部分……我知道，随着时间的推移，见解会逐渐显现）。

代码审查指南

这些准则源于代码审查应完成的任务。制定一套适用于所有情况的准则是不可能的。牢记这些目标将有助于即使在这些准则未涵盖的情况下也能实现代码审查的“精神”。

代码审查应该：

1. 验证代码是否是满足当前要求的正确且有效的解决方案。
2. 确保代码可维护。
3. 增加代码库的共享知识。
4. 通过定期反馈来提高团队的技能。
5. 不会对开发人员的时间造成繁重的负担。

作为开发人员

对于您来说，作为开发人员（或“作者”，“提交者”），对您将收到的反馈保持开放和谦虚的心态非常重要。

任何人都可以进行代码审查，并且每个人都必须接受代码审查；无论资历如何。请感激地接受任何反馈，将其视为学习和分享知识的机会。将任何反馈视为开放的讨论，而不是防御性的反应。

我们是人。人都会犯错。这完全正常。只要软件是由人编写的，就必然存在错误。

这并不意味着你应该粗心地编写代码或停止编写测试。但这种心态会消除对错误的恐惧，并营造一种接受错误的氛围。反过来，这对于在代码审查期间接受批评也至关重要。

经验交流

在代码审查期间，开发人员和审查人员正在交换最佳实践、经验、技巧和窍门。

开发人员和审阅者不仅在讨论代码……他们还在交流最佳实践和经验。代码审阅是建立和内化良好编码风格和最佳实践的绝佳途径。而且这种交流是双向的。因此，请将代码审阅视为宝贵的知识来源和学习机会。

作为审阅者

找到需要改进的代码只是成功代码审查的一小部分。同样重要的是，要以健康的方式传达反馈，并向同事表达同理心。

作为审阅者，务必注意反馈的具体语言。措辞对于你的反馈能否被接受至关重要。

正确： “我很难看出这段代码的作用。”
错误： “你写的代码很神秘。”

始终从个人角度出发，表达个人的想法、感受和印象，形成反馈。代码开发人员很难反驳个人感受，因为它们是主观的。

提交评论之前，记得设身处地为他人着想。很容易被误解，所以请仔细阅读评论，并始终保持尊重……说些好话对别人永远都是个好主意。

将开发人员排除在反馈之外

将开发人员排除在反馈之外；只讨论开发人员提交审核的代码。对代码的批评很难被当成针对个人的，因为你只是在谈论代码本身，这是一个客观的东西，而不是开发人员。同样，这将提高接受度（只要开发人员明白，他们不是他们的代码）。

非评判性合作

整个团队的态度和行为应该包含不带评判的合作，以学习和分享为共同目标；无论经验水平如何。

接受存在不同的解决方案

请记住，一个问题总会有不同的解决方案。您很可能有自己偏爱的解决方案，但开发者的解决方案也可能有效。区分常见的最佳实践和个人喜好。请记住，怀疑态度可能只是反映个人喜好，而不是错误的代码。

记住赞美

说“一切都很好！”完全没问题。代码审查的结果显示没有代码变更是合理的。不要强迫自己去找出代码中的问题。

最后，同样重要的一点：如果代码写得好，别忘了表达赞赏。表扬总是有益的，而且可以激励开发者。

谁应该审查

我个人认为，团队中的每个人都应该参与代码审查。从学习的角度来看，每个团队成员至少都应该查看发布描述。我曾经一度很匆忙，只是简单地查看一天中各个审查的评论。通过观察，我能够看到正在发生的变化。当我有更多时间时，我会积极地参与审查，努力改进代码库，一次查看一条评论。

培养积极的代码审查文化

同行代码审查可能会给团队人际关系带来压力。同事之间很难互相批评。因此，为了确保同行代码审查取得成功，管理人员在代码审查过程中营造一种协作和学习的文化至关重要。

虽然人们很容易将发现的缺陷视为纯粹的负面因素，但实际上，每个发现的缺陷都是团队改进代码质量的机会。代码审查还能让初级团队成员向高级领导学习，即使是最有经验的程序员也能借此改掉坏习惯。

代码审查中发现的缺陷不应被用来评估团队成员。如果审查指标成为薪酬或晋升的依据，开发人员会对审查过程产生敌意，并自然而然地专注于提升个人指标，而不是编写更优秀的整体代码。

拥抱代码审查的潜意识含义

知道自己的工作会被别人审查，自然会促使人们创作出更好的产品。这种“自我效应”自然会激励开发人员编写更简洁的代码，因为他们的同事肯定会看到。如果你的代码需要审查，这无疑会激励你仔细检查你的工作。

结论

代码审查是提升代码质量、建立最佳实践以及传播经验和知识的有效手段。它还能让开发者向同行学习、进行导师指导，并就他们的构建内容进行开放式对话和讨论。

为了获得最大的成功，代码审查需要一定的思维方式和措辞。因此，关注代码审查中的人为因素至关重要。

领先的EDJE