代码审查（Code Review）的本质

flower-field-250016_640.jpg

什么是代码审查？

代码审查是一个过程，即代码只有经过非作者本人评审后才能进入代码仓库。

代码审查的目的

但是大家为什么要做代码审查？不同团队的原因是各不相同的。笔者假设大家进行代码审查的目的是为了保证代码质量。如果继续问下去，为什么要保证代码质量？这是另一个问题，留给读者朋友思考。

这里还会有另一个问题：如果你写出来的代码质量高，那么，你是不是就不需要代码审查了？答案是肯定的。但是问题是你如何知道你写出来的代码质量是高的？

什么是代码质量

既然代码审查的目的是保证代码质量，那么，我们就必须回答什么是代码质量这个问题。

代码质量其实指的是软件系统的内在质量。那是软件系统最终用户看不到的，也不应该看到的。最终用户看得到的，称之为软件系统的外在质量。这在《代码大全》第二十章中有详细介绍。

该书中给出了代码质量的特性：

• 可维护性（Mantinability）
• 灵活性（Flexibility）
• 可移植性（Portability）
• 可重用性（Reusability）
• 可读性（Readability）
• 可测试性（Testability）
• 可理解性（Understandability）

本文假设《代码大全》是正确的。

代码可读性与可理解性之间的区别

有读者注意到可读性与可理解性似乎是同一特性。其实不是。

可读性与可理解性之间的区别是可读性强调的是细节语句，而可理解性强调的是系统设计层面。这好像高中生在做阅读理解题时，你认识文中的每个词，却你无法理解全文。

为什么代码审查能保证代码质量

既然我们实践代码审查的目标是为了保证代码的质量，那么，我们为什么认为代码审查能保证我们的代码质量呢？

作为Linux的创始人Linus会这样回答：足够多的眼睛，就可让所有问题浮现（given enough eyeballs, all bugs are shallow）。

但是多少眼睛才算足够多呢？反过来问：如果所有的问题没有被浮现，代表的是我们的眼睛不够多？这是另一个问题了。Linus的回答不足以证明代码审查能保证代码质量。

笔者认为应该以代码的特性为起点，重新审视代码质量的特性。你会发现所有的特性都是从旁观者的角度来看待的。也就是说只能由旁观者评判代码质量。而代码审查就是以旁观者的角度对作者的代码进行审查，基于此，我们认为代码审查是能保证代码质量的。

以下是为什么我认为代码特性是从旁观者的角度看待的：

• 代码可维护性是否好，由其他人向它增加一个功能的容易程度来证明；
• 代码是否灵活，当其他人为了某个特定的目的修改代码时，修改的难易程度才能证明；
• 代码是否具有可移植性，移植到其它环境的难易程度才能证明；
• 代码的可重用性如何，由其它系统使用它的难易程序证明；
• 代码可不可读，由代码评审人读懂该代码所花费的时间决定；
• 代码是否可测，这部分由测试覆盖率来决定；
• 代码的可理解性，由代码评审人理解代码所花费的时间决定；

但是，以上只是通过逻辑推理来证明代码审查能保证代码质量，并没有真正的证据证明。

代码审查能否真的保证代码质量，最终还是靠数据说话。所以，我们还必须想办法评估代码质量与代码审查之间的关系。

可理解性的重要性

在重新审视代码质量的特性时，我们注意到这些特性之间的关系。那就是代码的可理解性是其它特性的基础。如果你不理解你将要修改的代码，谈何维护、扩展、重用、移植、测试？就像演员不理解剧本，是无法表达电影中角色的情感的。

另外 ，从软件工程的成本角度来看。理解代码是我们工作的一部分，即理解代码是软件工程中一个必要成本。理解代码所花费时间越少，我们的成本越低。代码可理解性与软件工程的效率是正相关的。

基于这两个原因，我们认为代码的可理解性是非常重要的。也因此，我们在面临对代码质量的不同特性进行取舍时，代码可理解性应当作为权重最高的选项。

总结

代码质量有多种特性，这些特性都是基于旁观者视角的。而代码审查是旁观者评估这些代码特性的一个过程。我们希望通过代码审查这个手段来保证高质量的代码。这就是代码审查的本质。

然而，现实很骨感，同样的手段，用在不同的人，不同的组织上，效果却可能是千差万别。并不是你在团队中推广了代码审查，你们的代码质量就一定高的。就像过去，不少组织中推广“敏捷”，反而让团队更不敏捷一样。

如何做好代码审查，让代码审查真正发挥作用，是我们的另一个课题。