代码审查最佳实践

代码走查是可以有效提高软件开发人员代码质量的伟大工具之一。不过与其他工具一样，代码走查也有可能会被滥用。在其最近发布的一篇博文中，Kevin London 将其在 Wiredrive 的代码走查的原则具体化，并且为读者介绍了应用这些原则的最佳实践。

简而言之，代码走查是两个或多个开发人员针对用于解决某一问题的代码所提出的修改建议，所进行的讨论。有许多文章都谈及到代码走查的益处，如知识分享、代码质量以及开发人员成长等。不过在关于代码走查中所寻求的目标以及如何进行代码走查讨论方面的文章并不多。

代码走查所寻求的目标

体系架构 /设计

在体系架构 / 设计方面，建议遵循如下原则：

单一职责原则：每个类应该有且只有一个职责。更甚于此，我一般会将此原则应用于方法之上。对于某个方法来说，如果需要用“和”来描述方法的功能，那么该方法的抽象级别就可能是有问题的。
开 /闭原则：如果是面向对象的语言，那么是不是所有的对象都对于扩展是开放的，而对于修改是封闭的？
重复代码：关于重复代码，我遵循“三振出局法”。第一次出现代码拷贝，可以保持现状，暂不处理，尽管我并不喜欢这样。如果第二次出现代码拷贝，就需要进行代码重构，将公共的功能抽象出来。

在系统架构和设计方面，除了上述实践之外，还包括诸如斜视测试攻击、潜在缺陷、错误处理以及效率等。

编码风格

在编码风格方面，主要包含如下方面的最佳实践：方法命名、变量命名、函数长度、类长度、文件长度、文档注释、已注释代码、方法参数数量以及可读性等。

测试

从测试的角度来说，则需要从测试覆盖度、测试粒度、模拟器的数量、是否符合需求等方面考虑代码走查工作。

提前完成代码自检

在提交代码之前，要提前完成代码自检。使用 git add 添加有改动的文件或目录，然后运行 git diff --staged 命令检查尚未提交的改动。一般来说，会关注如下情景：

如何处理代码走查

在如何处理代码走查进程方面，Kevin London 提出了一系列关于代码讨论所用的手段。包括提出问题、称赞 / 强化良好实践、私下讨论细节、解释原因、对代码不对人、指出修复的重要性等。

关于心态

开发人员有责任保持可正常运转并且易于维护的代码。因此在代码走查的过程中，务必要保持开放的心态。虽然这对于所有人而言都并非易事。

一般来讲，对于审查人员所提出的建议，如果没有明确的不采纳理由，最好根据建议修改代码。如果审查人员对某行代码提出问题，也就意味着这行代码将来也会对其他人造成困扰。此外，代码改动有可能会帮助揭示出更大的架构性问题或缺陷。

参考资料

整洁代码艺术书单

关于代码走查最佳实践更多详细的介绍，请参考作者的博文

感谢崔康对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号：InfoQChina）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群）。