代码审查的实践经验

数百万年前，猿从树上下来，进化出了对生拇指，最终，变成了人类。

我们以类似的眼光来看下强制性代码审查（Code Review）：好像是一种能在软件开发这块广阔的领域里将人类从兽里分离出来的东西。

不过，我有时候会从我们的团队成员里听到下面这样的评论：

“这个项目的代码审查根本就是浪费时间。”
“我没有时间做代码审查。”
“我的项目发布延期了，都是因为我那懦弱的同事还没有做任何审查。”
“你能相信我的同事竟想让我在代码中改点东西吗？请向他们解释：如果我那最初的优雅代码受到任何方式改动的话，那就意味着宇宙微妙的平衡将要遭到破坏。”

为什么我们要做代码审查？

首先，让我们谨记为什么要做代码审查。对于任何专业的软件开发人员来说，最重要的目标之一是能够持续的提高他们的工作质量。即使你的团队里尽是优秀的程序员，你也不能将你自己与一个有能力的自由从业者区分开来，除非你能够作为一个团队工作。代码审查是达到这个目的的最重要方式之一。尤其，它们：

给予你第二双眼睛来找到做某些事的瑕疵和更好的方法。
确保至少有一个其他人员熟悉你的代码。
通过向新员工展示更有经验的开发者的代码来帮助训练他们。
通过让审查者和被审查者互相展示好的想法和做法以促进知识分享。
鼓励开发者在他们的工作中更加尽心尽力，因为他们知道自己的代码将来要被他们的的某个同事审查。

做彻底深入的审查

不过，如果不在审查工作上倾注一定的时间和精力，这些目标都是无法实现的。仅仅滚动浏览下patch，确保缩进正确、所有的变量采取小骆驼拼写法并不能构成一次彻底的审查。受到业界的启发也可以考虑结对编程，这是一个相当流行的做法，但也在所有的开发时间上增加了100%的额外开销来作为代码审查工作的基准。你可能会在代码审查中花费很多时间，但与结对编程相比，使用的总体工程时间仍少得多。

我认为花在代码审查工作上的时间应该是原开发时间的25%左右。例如，如果一个开发者花两天时间实现了个小项目，那么审查者应该花大致4个小时的时间来审查它。

当然，花在审查工作上多少时间并不是最重要的，只要审查能够准确无误的完成即可。特别地，你必须要能理解你正在审查的代码。这不仅仅意味着你只要懂该代码所采用语言的语法即可，它还意味着你必须了解该代码如何适应于更大的应用环境、组件或库下。如果你不抓住每一行代码的全部含义，那么你的审查就不是非常有价值的。这也是为什么好的审查都不可能非常快的完成：因为还要花时间去调查触发某个给定函数的不同代码路径，要去确保第三方API能够正确使用（包括任何边缘情况），等等。

除了寻找你所审查的代码中的瑕疵或其它问题之外，你还应该确保：

包含所有必要的测试。
合适的设计文档已经写完。

甚至擅长写测试和文档的开发人员也并不总能记得在代码改动之后及时更新。在适当的时候来自代码审查人员的细微调整对于确保代码在随着时间的推移不会变质是至关重要的。

防止代码审查工作超负荷

如果你的团队强制要求做代码审查，那这是有风险的，因为你的代码审查工作可能一直积压，最终到无法管理的地步。如果你两周之内不做任何审查工作，你可以很容易的花上几天时间来赶补它。不过这也意味着当你最终决定去处理它们的时候，你自己的开发工作将遭到一定的意外搁浅。这也使得做好审查工作更加困难，因为正确的代码审查需要强烈、持续的脑力劳动，很难这样数日保持下去。

因此，开发者每天应该竭尽全力的清空他们的审查积压工作。一个方法是早晨的第一件事情就用来解决审查工作。在开始自己的开发工作之前先做完所有的优秀审查工作，你可以防止以后的审查局面失控情况。有些人更喜欢在午休之前或之后或在一天结束后做审查工作。无论你什么时候做这些事情，通过将代码审查作为正规的日常工作而不是作为一种分散注意力的工作，你可以避免：

没有时间处理你的审查积压工作。
因为你的审查工作还没做完而延迟项目的发布。
做出一些不再相关的审查，因为在此期间代码已经改动的非常多。
因为赶在最后一分钟处理它们而导致审查工作最终完成的很差。

写易于审查的代码

无法管理的审查积压工作也不能全怪审查人员。如果我的同事不管三七二十一的花费一周的时间来给一个大工程项目添加代码，那么他们发布的patch将真的很难审查，因为在一个阶段里有太多的工作要处理，代码的目的和底层架构体系也会很难理解。

这是将你的工作切割为一个个可管理单元之所以非常重要的众多原因之一，我们使用scrum管理方法，所以对我们来说合适的单元是重点。通过一起努力，用单元来组织我们的工作，并提交仅与我们正在进行的某个单元相关的审查，我们可以写出更加易于审查的代码。你的团队可能使用另一种管理方法，但是原则都是一样的。

为了写出易于审查的代码，还有一些其它的必备条件。如果要做出一些很棘手的架构决策，为满足审查者的要求，事先进行讨论是合理的。这将使得审查者更加容易的理解你的代码，因为他们将知道你在代码中试着达到什么目的以及怎么计划来达到该目的。这也有助于避免这样一种情况：在审查者提出一个不同的更好的方法后，你必须要重写你的大段代码。

在你的设计文档里项目架构应该要详细的描述。这无论如何都是很重要的，因为它能让一个新的项目成员很快的赶上进度并理解现有的代码库。它还能帮助审查者更好的做好自己的工作，这是另一个好处。单元测试也有助于向审查者说明组件应该如何使用。

如果你的patch里包含了第三方代码，请单独提交。例如当jQuery的9000行代码被插入代码中间时，要做好代码审查工作就难上加难了。

写出易于审查的代码的最重要步骤之一是给你的代码审查部分添加注释。这表示你可以自己浏览审查部分，并在任何你觉得有助于审查者理解代码意思的地方添加注释。我发现这样的注释仅花费相对较少的时间（经常仅几分钟的时间）却能产生巨大的作用，能让代码审查工作完成的更快、更好。当然，代码注释也有许多相同的优点，应该在合适的地方使用，但是通常来说审查注释更为明智。最后可以说是一个奖励吧， 研究表明，当开发者重新阅读和注释代码时，竟然发现他们自己的代码里有很多的瑕疵。

庞大的代码重构

有时有必要重构能影响许多组件的某个代码库。对于一个庞大的应用程序，这个过程可能花费好几天（甚至更久）且导致庞大的补丁。在这些情况下一个标准的代码审查工作可能是不切实际的。

最好的解决方法是递增式重构代码。在工作代码库的合理范围内找到能达到你目的的某个改动点。一旦改好了，review通过了，接着进行下一个改动，直到整个重构工作完成。这个方法可能并不是每次都行得通，但是有想法和计划，在重构时要避免巨大的补丁通常是实际可行的。像这样来重构代码可能要花开发人员更多的时间，但它同时也产生了更好的代码质量和更容易的审查工作。

如果真的实现不了递增式重构代码（这可能要说一些关于如何写好和组织好源代码的事情），一个可能的解决方案是当进行重构工作时用结对编程来代替代码审查。

解决争议

你的团队无疑是由一群聪明的专业人士组成。当大家对某个确定的编码问题观点不同时，基本上都会产生争议。作为一名开发人员，保持开放的心态，在你的审查者更倾向于一个不同的方法时要随时准备妥协。不要对你的代码持专有的态度，也不要带个人审查意见。如果仅仅是因为有人觉得你应该将一些重复的代码重构为一个可重复利用的函数时，这并不能表明你就不是一个有吸引力的、出色的和有魅力的人。

作为一个审查者，一定要机智。在改变建议之前，认真考虑下是否你给的提议真的更好或仅仅只是你个人风格问题。如果你选择的战场集中在一些源代码中明显需要改进的区域，你将能获得更多的成功。说一些诸如“考虑下……可能是值得的”或“有人建议……”的话更适合，而不是“连我的宠物仓鼠都能写出一个比这更高效的排序算法”。

如果达不到一个中间立场（即双方都不愿意妥协），那么就邀请一个双方都尊敬的第三方开发人员过来看看，让他们给出一些观点和建议。

本文文字及图片出自伯乐在线