改进代码审查的10种方法

改进代码审查的10种方法

     所有这些建议（除了第一条）都假定你的代码是作为Pull Request工作流程的一部分来审查的，比如GitHub流程或基于树干的PR开发。还有其他的代码审查方法，但它们不那么普遍，所以我今天不讨论它们。

1. 结对编程
让我们先把明显的答案说出来。

       结对编程是指两个开发人员坐在一个键盘前（可能是通过屏幕共享的虚拟方式），并在口头上共同完成一段代码的做法。控制键盘的人，被称为驱动者，可以与观察者或导航者互换角色，可能是定期的，也可能是临时的。关键是，所有的代码都是由两个开发人员实时看到的。正如支持者所指出的，驱动者和导航者的独特角色也使大脑的不同部分参与其中，这使得这对组合比单独工作的单个开发人员更有效。通过这样做，所有的代码在写完后就被 "完美 "地审查。许多团队认为这就避免了后期异步代码审查的需要，尽管意见不同。当然，结对编程并不是所有的团队都能做到，也不是所有的时候都能做到。如果你想结对的伙伴在不同的时区工作，或者仅仅是有不同的时间表，如果公司的政策禁止这种做法，如果你只是对它感到不舒服，或者如果你认为即使在结对编程后，另一个审查通道是有价值的，继续阅读。

2. 创建小型pull request
提交一个10行的拉动请求，审查将需要10分钟并发现6个问题。

提交一个1000行的拉动请求，审查将需要10分钟，并发现零问题。

这可能看起来有点违反直觉，但我所知道的获得深入代码审查的最好方法是使你的PR更小。人类喜欢小的、可消化的数据片段，这是一个公认的事实。即使数据的绝对数量相同，将大数据集分割成较小的数据集也能帮助我们更有效地消费它们。这就是为什么报纸的栏目很窄，为什么文章要用插图和小标题来分割。因此，从逻辑上和经验上看，10个100行的PR会比一个1000行的PR得到更好的审查，即使它们包含完全相同的变化。作为一个代码作者，保持你的PR很小，并且容易审查。作为一个评审员，当你看到一个大的PR时，请作者把它分成几个小的PR。

3. 小批量的工作
      这与创建小型拉动请求密切相关。为了避免你写出1000行的补丁，然后在审查前分成10个小的PR，请考虑小批量工作的好处:

更频繁的PR意味着更频繁的反馈
作为一个作者，小的、有针对性的PR更容易被考虑到
小的PR往往能更快得到审查
小的PR有较少的合并冲突
也许还有一个最反直觉的理由，那就是使用较小的PR。

当团队中的每个人都习惯于小批量的工作时，就更容易审查其他人的工作，而不会受到有害的干扰。

4. 将代码审查置于编写代码之上
      当我们需要几个小时或几天的时间来审查代码时，我们往往会在每次审查中放入更多的代码。这就导致了更大的拉动请求。较大的拉动请求需要更长的时间来审查，所以审查员倾向于将其推迟。这反过来又意味着需要几个小时或几天的时间来审查代码......为了摆脱这种消极的反馈循环，我们需要对流程中的每一个步骤进行攻击。更小的、更频繁的拉动请求，正如已经讨论过的，只是其中的一部分。另一个关键部分是频繁的代码审查。一个简单的规则可以让你的团队摆脱这种习惯。在写代码之前一定要审查代码。当你坐下来开始一天的工作时，在打开你的IDE之前，看看是否有任何等待审查的代码。当你创建一个PR时，在开始你的下一个任务之前，看看是否有任何等待审查的代码。攻击代码审查就像攻击铁蒺藜一样，如果不立即消灭它们，它们就会大量繁殖和扩散。当这个建议和前面的两个建议一起使用时，你会很快发现你的整个团队都在以快速的节奏进行编写-审查-合并，这需要一个小时或更少的时间。合理的下一步可能是同行编程，以进一步减少周期时间。

5. 用一个工具强制执行风格化
      停止审查编码风格。认真的。停止它。这是对每个人的时间和精力的巨大浪费。而且，它往往充满了不必要的情绪。

使用一个代码格式化工具。把它添加到你的预合并自动化中。如果PR中的任何代码不符合标准，它应该自动不通过PR。你使用哪种风格比你的风格被自动执行的事实要重要得多。我不知道你怎么想的，但我肯定更喜欢一个工具告诉我应该使用制表符而不是空格，而不是一个同事告诉我。也许我对这个工具很生气，但至少我以后不必在午餐时坐在这个工具的对面。把这些时间和精力留给审查代码的功能和结构。

6. 使用Linters
大多数语言都有大量的提示符。使用它们。使用他们中的许多人。提示器不仅可以提高代码的质量、安全性和复杂性，而且可以从代码审查者那里卸载一定的认知负荷。

7. 编写可读的代码
代码的可读性是主观的。但它也是极其重要的。

任何傻瓜都可以写出计算机可以理解的代码。好的程序员写的代码是人类可以理解的。
- Martin Fowler

     作为一个代码作者，写代码时要考虑到你的（人类）读者。作为一个代码评审员，在代码评审过程中，当你发现自己在想 "WTF？"的时候，请留下评论，以便改进。即使你自己想通了，这也是一个很好的机会，让作者学会写出更多可读的代码。这也是后辈们应该积极参与审查前辈们的代码的原因之一。

8. 只做一件事
       每一次提交，每一次拉动请求都应该做一件事，而且只做一件事。你在添加功能时发现了一个错误吗？在一个单独的PR中提交错误修复。你需要重新格式化整个文件以符合新的格式化规则吗？那就做一个单独的报告。没有什么比试图审查一个错误修复、新功能和性能改进都混杂在一个PR中更难了。 尽早提交。经常提交。提交，以及PR，都是免费的。

9. 编写描述性的提交和PR信息
      代码审查不仅仅是关于代码。提交和公关信息也是拉动请求的一个有意义的部分。当你试图调试某个已经不在公司的人在9个月前所做的事情时，没有什么比一个只写着 "修复 "的300行修改的提交信息更令人沮丧的了。

10. 要有礼貌
      不要把代码审查作为展示你高超技术能力的借口。要有礼貌。提供友好的改进建议。要谦虚。当你的建议只是一个意见，而不是你的交易障碍时，要诚实。没有人喜欢粗鲁的评审员，他们会想方设法避免他们。这意味着，让代码作者开放，创建小的、容易审查的PR，并普遍接受这个系统的最好方法是使代码审查尽可能地令人愉快。这意味着让他们有礼貌，并使他们成为双向学习的机会。

如有想了解更多软件设计与架构, 系统IT,企业信息化, 团队管理 资讯，请关注我的微信订阅号：

作者：Petter Liu
出处：http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。 该文章也同时发布在我的独立博客中-Petter Liu Blog。