如何使您的代码审查员爱上您
当人们谈论代码审查时，他们专注于审查者。但是，编写代码的开发者与阅读者一样，对审查同样重要。几乎没有指导您编写代码进行审查的指南，因此作者常常出于纯粹的无知而将这一过程搞砸了。
本文介绍了当您是作者时参与代码审查的最佳做法。实际上，在这篇文章的结尾，您将非常擅长发送代码进行审核，以至于您的审核者会真正爱上您。
但我不希望我的审稿人爱上我🔗︎
他们会爱上你的。处理它。没有人在临终前抱怨过太多人爱上了他们。
更快地了解：如果您正确地准备了更改列表，它将使审阅者的注意力转移到支持您的成长而不是无聊的风格违规的领域。当您对建设性批评表示赞赏时，您的审稿人会提供更好的反馈。
使其他人变得更好：您的代码审查技术为您的同事树立了榜样。有效的作者做法会削弱您的队友，使他们在向您发送代码时更加轻松。
最小化团队冲突：代码审查是造成冲突的常见原因。认真而认真地对待它们可以减少争论。
这个建议听起来很明显，但是我经常看到作者像对待个人质量保证技术人员一样对待审稿人。这些作者竭尽全力发现自己的错误或设计变更列表以供审核。
您的队友每天都会集中精力集中工作。如果他们将其中的一部分分配给您，那就是他们无法花费自己的时间的时候。您可以最大限度地利用他们的时间，这是公平的。
当两个参与者彼此信任时，评论会大大改善。当他们可以指望您认真对待他们的反馈时，您的审阅者会付出更多的努力。将审阅者视为必须克服的障碍，这限制了他们为您提供的价值。
在向您的队友发送代码之前，请自己阅读。不要只是检查错误-想象一下第一次阅读代码。有什么可能会使您感到困惑？
我发现在编写代码和检查代码之间稍作休息会有所帮助。人们通常会在一天结束时取消更改，但是那时候您很可能会忽略粗心的错误。等到早晨，再将新鲜的眼睛看着变更列表，然后再将其移交给您的队友。
尽可能采用您的审阅者的环境。使用他们将看到的相同的差异视图。与常规源代码编辑器相比，在差异视图中发现愚蠢的错误要容易得多。
不要期望自己是完美的。不可避免地，您将发送一个更改列表，其中包含您要删除的调试代码或要排除的杂散文件。这些错误不是世界末日，但值得我们跟踪。注意您的错误模式，并考虑创建系统来防止它们。如果它们发生得太频繁，则会向您的审阅者发出信号，表示您不珍惜他们的时间。
在上一份工作中，作为开发人员指导计划的一部分，我定期会见一位高级工程师。在我们第一次见面之前，他请我带上我写的设计文件。当我将其交给他时，我解释了该项目是什么以及它如何与我的团队目标保持一致。我的导师皱了皱眉。他直截了当地说：“您刚才告诉我的所有内容都应该在设计文档的首页上。”
他是对的。我写了设计文档，想像我的队友将如何阅读它，但是我没有考虑其他读者。除了我的直接队友之外，还有更广泛的听众，包括合作伙伴团队，导师和晋升委员会。他们都应该也能够理解该文档。从那次讨论开始，我一直在思考如何构建我的作品以解释其背景。
您的变更列表说明应总结读者需要的所有背景知识。在编写说明时，您可能会想到一个代码审阅者，但是他们不一定具有您所想象的上下文。此外，您的其他队友也可能需要阅读此更改列表，将来的读者在回顾更改历史时应了解您的意图。
良好的变更列表说明从总体上说明了变更所能实现的目标以及进行此变更的原因。
要深入研究编写出色的变更列表说明，请参阅Chris Beams的“如何编写Git提交消息”和David Thompson的“我最喜欢的Git提交”。
如果您依靠审稿人告诉您何时花括号用错了线，或者您的更改破坏了自动测试套件，那是在浪费他们的时间。
自动化测试应成为您团队标准工作流程的一部分。在所有自动检查均在连续集成环境中通过后，审核开始。
如果您的团队受到严重误导，并且拒绝投资进行持续集成，请自己进行自动化检查。向您的开发环境中添加git pre-commit钩子，短绒和格式化程序，以确保您的代码遵守正确的约定并在每次提交时保留预期的行为。
作者帮助我理解了该功能，但是下一个阅读它的人呢？他们是否应该深入研究变更历史并曾经阅读过每个代码审查讨论？更糟糕的是，当作者来到我的办公桌前给我当面解释时，这既打断了我的注意力，又确保了其他任何人都无法访问该信息。
当您的审阅者对代码的工作方式感到困惑时，解决方案不是向那个人解释它。您需要向所有人解释。
回答某人问题的最好方法是重构代码并消除混乱。您可以重命名事物或重组逻辑以使其更清晰吗？代码注释是可以接受的解决方案，但绝对不如自然地编写文档的代码。
范围蠕变是代码审查中常见的反模式。开发人员开始修复逻辑错误，但他们在此过程中注意到UI缺陷。他们认为，“虽然我在这里，但我会解决其他问题。”但是现在他们把事情弄糊涂了。他们的审阅者必须弄清楚哪些更改服务于目标A，哪些更改服务于目标B。
最好的变更列表只是做一件事情。更改越小越简单，审阅者就越容易将所有上下文保持在头脑中。将不相关的更改脱钩，还可以使团队成员之间的审核并行化，从而减少更改的周转时间。
没有代码审查经验的开发人员通常会违反此规则。他们将进行两行更改，然后他们的代码编辑器会自动重新格式化整个文件。开发人员要么无法识别他们做了什么，要么认为新的格式更好。他们发出两行功能更改，这些功能更改埋在数百行非功能空白更改中。
混乱的变更列表是对您的审阅者的极大侮辱。仅空白的更改很容易查看。两行更改很容易查看。在空白空间的海洋中丢失的两行功能变化既乏味又令人发疯。
开发人员在重构时也倾向于不适当地混合更改。当队友重构代码时，我喜欢它，但是当他们在更改代码行为时重构时，我讨厌它。
如果一段代码需要重构和行为更改，则应在两到三个更改列表中进行：
通过使步骤2中的自动化测试保持不变，您可以向审阅者证明重构可以保留行为。当您到达第3步时，您的审核者就不必从重构更改中解脱出行为更改，因为您已经提前将它们分离了。
太大的变更列表是范围蠕变的丑陋表亲。假设开发人员发现为了引入功能X，他们必须修改现有库A和B的语义。如果这是一小组更改，那很好，但是太多的此类修改会使更改列表变得巨大。
变更列表的复杂度随着其接触的代码行数量呈指数增长。当我的更改超过400条生产代码时，我会寻找机会将其分解，然后再要求进行审查。
您可以先更改依赖关系，然后在后续的更改列表中添加新功能，而不是立即更改所有内容吗？如果现在添加功能的一半，并在下一个变更列表中添加另一项功能，是否可以使代码库保持健全状态？
分解代码以找到可以进行有效且可理解的更改的子集很繁琐，但可以产生更好的反馈，并减轻了审阅者的负担。
破坏代码审查的最快方法是亲自获得反馈。这是具有挑战性的，因为许多开发人员对他们的工作感到自豪，并将其视为自己的扩展。如果您的审阅者巧妙地将他们的反馈视为人身攻击，那就更难了。
作为作者，您最终可以控制对反馈的反应。将审阅者的注释视为对准则的客观讨论，而不是作为人的个人价值。做出防守反应只会使事情变得更糟。
我尝试将所有注释解释为有用的课程。当审阅者在我的代码中发现一个令人尴尬的错误时，我的本能是找借口。取而代之的是，我抓紧自己并赞扬我的审稿人的谨慎。
出乎意料的是，当您的审阅者发现代码中的细微缺陷时，这是一个好兆头。这表示您打包好了变更列表。由于没有格式错误和名称混乱等所有显而易见的问题，您的审阅者可以深入关注逻辑和设计，从而获得更有价值的反馈。
审核者有时会断然错误。正如您可能不小心编写错误的代码一样，您的审阅者也会误解正确的代码。
许多开发人员对审阅者的错误采取防御措施。他们以冒犯他人侮辱自己的代码为耻，这甚至是不正确的。
即使您的审稿人弄错了，那仍然是一个危险信号。如果他们误读了，别人也会犯同样的错误吗？读者是否必须进行异常级别的审查才能确保自己没有特定的错误？
寻找重构代码的方法，或添加使代码更明显正确的注释。如果混淆是由模糊的语言功能引起的，请使用非专家可理解的机制来重写代码。
我经常遇到这样的情况：我给别人做笔记，他们更新他们的代码以解决我的一些反馈，但是他们没有写任何答复。现在，我们处于模棱两可的状态。他们是否想念我的其他笔记，或者他们还在工作？如果我开始新一轮的审核，则可能会浪费时间在未完成的变更列表上。如果我等待，我可能会造成一个僵局，我们俩都希望对方继续下去。
在您的团队中建立约定，以便随时清楚谁在“握着警棍”。作者正在进行编辑，或者审阅者正在撰写反馈。永远都不会因没有人知道谁在做什么而导致程序停顿的情况。您可以通过更改列表级别的注释来轻松完成此操作，这些注释指示何时来回传递控件。
对于需要采取措施的每个便笺，请明确回答以确认您已解决。一些代码查看工具可让您将注释标记为已解决。否则，请为每个音符遵循一个简单的约定，例如“完成”。如果您不同意该说明，请有礼貌地说明您为什么拒绝采取行动。
根据您的评论者的努力调整您的回复。如果他们写了详细的说明以帮助您学习新知识，则不要仅将其标记为已完成。若有所思地回应，以感谢他们的努力。
有时，代码复习笔记为解释留下了太多的空间。当您收到诸如“此功能令人困惑”之类的评论时，您可能想知道“令人困惑”的含义是什么。该功能是否太长？名字不清楚吗？是否需要更多文档？
长期以来，我一直在努力澄清含混不清的音符，但听起来并不具有防御性。我的直觉是问：“这有什么令人困惑的地方？”但这听起来很gr脚。
一次，我无意间给队友发了一张模糊的纸条，他以一种令人惊奇的方式解除了武装：
我喜欢这种回应，因为这表明缺乏防御和公开批评。每当审阅者给我不清楚的反馈意见时，我总是会做出一些“有帮助吗？”的变化。
另一种有用的技术是猜测您的审阅者的意图，并根据该假设主动编辑您的代码。对于“这很令人困惑”之类的注释，请重新看一下您的代码。通常，您可以采取一些措施来提高清晰度。修订版本会通知您的审核者，您可以更改，即使不是他们所考虑的版本。
在网球比赛中，如果不确定对手的发球范围是否超出范围，则可以给他们带来疑问的好处。对代码审查应该有类似的期望。
有关代码的某些决定取决于个人喜好。如果您的审稿人认为您的8行功能会比两个5行功能更好，那么您俩都不是客观上的“正确”。哪个版本更好是一个问题。
当您的审稿人提出建议时，并且每个人都有大致相等的证据来支持您的立场，请交给您的审稿人。在你们两个之间，他们对于重新阅读此代码有什么更好的了解。
几个月前，一个用户为我维护的一个开源项目做出了很小的改变。我在几个小时内给了他们反馈，但是他们很快就消失了。几天后，我再次检查，但仍然没有任何回应。
六个星期后，这位神秘的开发人员再次出现并提交了他们的修订版。当我赞赏他们的努力时，两轮审阅之间的间隔使我的工作量增加了一倍。我不仅必须重新阅读他们的代码，而且还必须重新阅读我的反馈以恢复对讨论的记忆。如果他们在一两天内跟进，我就不必做所有这些额外的工作。
六周的停顿是极端的，但我经常看到队友之间漫长而不必要的延迟。有人发出变更列表以供审核，接收反馈，然后将其放回一个星期，因为另一个任务分散了他们的注意力。
除了在还原上下文中浪费时间之外，半成品变更列表还会增加复杂性。它们使每个人都很难跟踪已经合并的内容和正在运行的内容。有了部分完成的变更列表，合并冲突就会更多，没有人会喜欢解决这些冲突。
发出代码后，将审查推进为最高优先级。延迟最终审阅时间会浪费您的审阅者，并增加整个团队的复杂性。
在准备下一个变更列表进行审核时，请考虑您控制的因素，并用它们有效地指导审核。当您参与评论时，请寻找阻碍进度或浪费精力的模式。
记住黄金法则：珍惜评论者的时间。当您允许审阅者专注于代码的有趣部分时，审阅者会生成高质量的反馈。如果您要求他们解开您的代码或警告简单的错误，那么你们俩都会受苦。
最后，进行周到的沟通。简单的误解或粗心的评论容易使评论脱节。在批评别人的作品时，情绪高涨，所以要注意陷阱，这可能会使您的审稿人感到受攻击或不尊重。
恭喜你！如果您已达到这一点，那么您现在是专家审阅者。评论者可能会爱上您，因此请善待他们。
在过去的三年中，我撰写了17篇帖子，这些帖子到达了Hacker News的首页，其中有五篇达到了第一名。在同一时期，我的许多帖子绝对失败了，无所作为。
现在，我将分享在博客方面的成功与失败所带来的教训，以教会您如何选择主题，撰写文章以及对结果进行迭代，从而在Hacker News，reddit和Twitter上吸引技术精湛的受众。
学到更多
如何像人一样进行代码审查：既然您已经从作者那边学到了有效的做法，那么当您成为审查者时，要学会改进代码审查。
