改进代码审查的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，并普遍接受这个系统的最好方法是使代码审查尽可能地令人愉快。这意味着让他们有礼貌，并使他们成为双向学习的机会。

---

今天先到这儿，希望对云原生，技术领导力， 企业管理，系统架构设计与评估，团队管理, 项目管理, 产品管管，团队建设 有参考作用 , 您可能感兴趣的文章:
领导人怎样带领好团队
构建创业公司突击小团队
国际化环境下系统架构演化
微服务架构设计
视频直播平台的系统架构演化
微服务与Docker介绍
Docker与CI持续集成/CD
互联网电商购物车架构演变案例
互联网业务场景下消息队列架构
互联网高效研发团队管理演进之一
消息系统架构设计演进
互联网电商搜索架构演化之一
企业信息化与软件工程的迷思
企业项目化管理介绍
软件项目成功之要素
人际沟通风格介绍一
精益IT组织与分享式领导
学习型组织与企业
企业创新文化与等级观念
组织目标与个人目标
初创公司人才招聘与管理
人才公司环境与企业文化
企业文化、团队文化与知识共享
高效能的团队建设
项目管理沟通计划
构建高效的研发与自动化运维
某大型电商云平台实践
互联网数据库架构设计思路
IT基础架构规划方案一(网络系统规划)
餐饮行业解决方案之客户分析流程
餐饮行业解决方案之采购战略制定与实施流程
餐饮行业解决方案之业务设计流程
供应链需求调研CheckList
企业应用之性能实时度量系统演变

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

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