同行代码审查实战分析

数百万年前，人类祖先人猿学会直立行走——解放双手——最终进化到人；而代码审查在开发过程中有着异曲同工之妙——区别出野蛮开发和先进开发。 

 

然而，在实际工作中，以下声音总不绝于耳： 

• “代码审查在项目中简直就是浪费时间！”
• “我根本没有时间去做复查。”
• “由于我那个谨慎的拍档还没做好复查，进度只能延后了。”
• “你确定，我的同事要求我修改代码吗？请向他们解释一下，任何轻微地改动都会让我的代码失去原有的优雅。”

那么问题来了，我们为什么需要做代码复查？ 

作为专业的软件开发人员，持续提高代码质量是工作生涯不断追求的目标之一。无论我们有多么优秀，都离不开团队；而代码复查是个人与团队的润滑剂： 

• 当局者迷，旁观者清。代码复查如同为我们安装了后视镜；
• 使我们的代码多了至少一个知音人；
• 能帮助新员工在这个过程中学习和领悟到前辈的代码精髓；
• 有助开展知识共享，众“智”成城。

要做就要做到最好 

如果想要达成上述种种美好结果，是离不开时间和工作的科学安排的。仅仅做好代码缩进、变量命名规范等基本工作，还不能算得上完美。而如果曾经尝试过结对编程，或许你会发现其所花的时间往往都比代码复查要多。 

我的建议是用开长总时长的四分之一时间来进行代码复查。举例来说，如果开发总用时为两天，那么应该花上大约四个小时来进行复查。 

当然，如果能把事情做对，可不必拘泥于时间的多少。进一步说，我们必须能看明白将要复查的代码。这不仅代表要掌握基本的语言语法，更关键的是要掌握整个代码的架构，所用组件或库等细节。如果不能做到对每一行代码所做的事情都了然于胸，这样的复查工作是没有多少价值的。所以要做好这点是不能一味讲求速度的，必须花一番功夫来从头到尾对代码进行梳理分析。 

此外还有两件事是务必要做到的： 

• 复查工作中包含所有必须的测试工作；
• 做好设计文档的编写工作。

避免拖延症 

今天的工作今天完成是最完美的工作状态，否则一旦拖延症出现，再多再好的复查都只会成为开发过程中的绊脚石。好的复查需要紧密而持久的努力，不是搞搞突击就能做好的。 

因此，开发者应当尽力做到日清日结。把复查作为每天工作的开端是个不错的主意；理清旧的思路将有助于开展新的编码任务。也或许有的人喜欢在午休或下班前进行，无论在什么时候进行，以下几点是应该避免的： 

• 让积压工作越积越多；
• 由于复查没有做好而导致进度延后；
• 由于代码更新频率快就放弃做复查；
• 往往在最后一刻才去做复查。

编写出可复查的代码 

不应该把所有复查工作都推给复查员。如果我的同事花了一周时间添加了看起来比较乱的代码，这对复查工作无疑是重大打击，也很难让人摸清其思路和结构。 

所以我们在编程时，要有意识地把代码划分为可操作单元。我们使用的方法是scrum，它为我们的开发工作做了很明晰的指导，同时使得整个开发过程有迹可循，便于进行追溯和回顾。 

其次，在与复查员进行讨论前要搞好关系。这样将有助于双方对彼此有所了解，从而减少讨论时矛盾发生的机率。 

再者，项目结构应当在设计文档中描述得清楚具体。这对于项目新成员的成长是大有裨益的，同时能帮助复查员提高工作效率。 

最后也是最重要的一点是在自我复查过程中做好注释。换言之要先自行对代码过一遍，把需要做出说明的地方标示出来并解释清楚。有研究表明，开发者在对自己的进行复查和注释时，经常会找出不少瑕疵。 

大型代码重构 

有时候如果需要进行代码重构，这势必会影响到很多组件，特别是较大型的应用。在这种情况下，最好的解决方案是逐步推进重构工作。先对要做的变更进行划分，然后根据修改意图进行分段式重构。当这部分变更完成并做好复查后，再执行第二部分的重构，重复该步骤直至完成全部工作。这或许增加了重构用时，但会带来更高质量的代码同时可以减轻复查员的工作量。 

如果实际情况真的不允许进行逐步重构，可以试试结对编程。 

解决矛盾 

在一个技术团队中，各人有各自的观点，如何达成共识是成败的关键。作为开发者，应该保持开明的心态并虚心接受不同的意见。避免固步自封，避免对自我复查工作的不屑一顾。如果有人提议把我们一些重复的代码做成一个可复用函数，这并不代表我们之前的工作是毫无价值的。 

而作为复查员，要懂得人情世故。在给出修改意见前，先考虑清楚这真的会更好抑或仅仅是风格上的不同看法。提议说法可以是：“如果尝试另一种方法，或许会更好”或“有同事建议这样做”，而要避免的是：“就连我家宠物都能写出比这好的算法！” 

如果真的一时僵持不下，争议双方不妨请教第三个开发人员，从他的角度来再次审度各自的观点，直到形成共识，三人行，必有我师焉。 

 

from http://www.iteye.com/news/30155