疯狂java


您现在的位置: 疯狂软件 >> 新闻资讯 >> 正文

代码审核要早且多


 

许多程序员厌恶、憎恨或双倍不喜欢代码评审,但实在没有理由去恨它们。其实,有经验的程序员还期待代码审核—我们很快将看到原因。

人和观点

如此多的代码审核以失败告终的原因在于:程序员将他们代码的价值和自身的价值画上等号。当审核者指出代码中的问题时,程序员将之视为一种攻击,并且采取防卫姿态,整件事情于是很快急转而下。

我们要清楚地认识到这一点:审核者将找出你代码中的错误。我敢保证,绝对会找到。但那并不意味着你的技术就很糟糕。改进的空间总是存在;或者对于你的代码该如何书写,至少存在不同观点。将代码评审核为一种开放式讨论,而不是一种你是被告的审判。

“错误”的范围可以从Bug到风格问题。Bug简单,你必须修复它们。每个人,菜鸟和专家都一样,不时会犯错,因此屋子里没人会认为你就是白痴。把问题记下来,然后继续前进。

更具有争议性的问题在面对风格问题时产生。可能你正在使用带计数器的循环,资深程序员审核你的工作时建议换成迭代器。这表明你的代码有错和该建议正确吗?不,风格问题没有那么绝对。

既然这是一场开放式的讨论,那就可以深入探讨这个建议的优点。审核者可能会说:“使用迭代器消除了差一(off-by-one)错误的可能性。”不要产生防御心理并争辩:“可我的循环没有差一问题!”审核者已经看到了。他想说的是:换种方法消除那种可能性是好风格。

一旦理解了审核者的意思,就要感谢他的建议,记下来,继续前行。在你有时间让代码审核的紧张感消失之后,考虑你的行动计划。风格上的异议会因为人身攻击引发争议;若在没有他人在场的情况下考虑这种异议的优点,你可能会发现审核者有一定的道理。

观点是本质:无关乎你和审核者的对错。它关乎好的代码和更好的代码。

形式

我将描述我看到过的代码审核的形式,并就它们给你一些提示。

非正式审核

你经常会被某些东西难住,这时需要有人来帮你解决它。或者可能是,你发现这是个好的解决方案,但你拿不准。去找个更有经验的程序员。就算是脾气再不好的人这时也往往会先忍住,被征求意见的恭维甚至能软化脾气最差的人。

伙伴系统

有些项目要求凡是要检入代码库的代码都要有“伙伴”签字。你完成了变更,也测试过了。现在,你需要有人在检入前对其评审。不要只找跟你要好的同事,他们会对你写的任何东西大开绿灯。去找你更改部分的领域专家。要是找不到,那就去找一个跟你不太熟的同事。

将伙伴系统作为一种让更多人熟悉你工作的方法。尤其当你是新人的时候,没有什么比用代码来建立自己的公信力更好的方式了。它不需要是耀眼、巧思、别出心裁的代码—只需要是可靠的代码。确保人们可以定期地见到它。

高层审核

这往往是多人参加的有投影仪的正式审核会。往往审核数周的工作成果,但以一种高层次的观点来看。你解释设计,解释它如何转换到代码,然后审核代码的关键部分。这是一次讨论设计和风格的机会。准备好挨批评,记住在前面的“人和观点”一节讨论过的问题。

作为审核员,我最喜欢的问题是“给我看测试”。我对我领导的每个项目都要求自动化测试,因此,要是对这个问题的反应是一片茫然,审核就结束了,我们将在下周安排一次新的审核。不管怎样,有经验的程序员会从浏览测试开始审核。没有什么比展示测试更能确立对你代码的信心了。

逐行审核

最无聊、让人觉得压抑的代码审核就是每人逐行检查代码。实际上,这类审核往往是为那些已经成为灾难的代码准备的。(最好不是你的代码。)假设你处于捉虫模式,对每行代码都要问:这行的假设是什么?哪些方法会让它失败?万一失败了会怎样?

如何避免这种对你代码的逐行审核?简单:让你的代码早点审核,而且经常审核。采用非正式或伙伴系统,或安排组内审核。我一开始说过:有经验的程序员渴望代码审核。这是因为他们更愿意早点得到反馈,避免陷入需要逐行审核的麻烦里。

审查

我从别人那里听到这个实践,但自己从未用过。在审查过程中,资深程序员审视你的整个项目,深入到具体主题。我说的“深入”其实是顺藤摸瓜的意思。为何你要选择某某设计?你有哪些数据证明你的假设?如何证明(或测试)你的实现是正确的?要是它能扔木头,它每秒可以扔多少木头?明白了吧。

准备审查是件大事,因为你不知道审查员会问什么。你必须准备任何事情。我在这里唯一的建议就是:在编程时,问自己同类问题。要是你的程序是从文件中读取数据,问问自己,我对文件格式做了什么假设?我是如何测试这些假设的?文件可以有多大?我如何证明?

当然,你目前可以只采用一种方式。但这种思维方式的回报总会在某个时间点开始递减;这个时间点取决于项目的类型和它的生命周期阶段。对于产品代码,小心谨慎为佳;对于商展示例或概念证明,只需完事就万事大吉了。

代码审核策略

关于代码审核策略的范围从不存在直到有制度保证。若团队的开发风格处于极度混乱的状态,除非迫不得已,他们不会去做代码审核。那时,等待你的将是侵蚀生命的逐行审核。若团队采用像极限编程这样的开发实践,代码审核就是常态:XP的结对编程,在效果上就是边写代码边审核。

有的行业出于认证的目的要求代码审核。如果你正在为航空电子或核电站写软件,在发行软件之前,会有一个令人发抖的审核过程。你知道有好多软件都附带一个最终用户许可证协议,上面基本上写的都是软件没有保修期且随时有可能崩溃吗?在航空电子业可没有这种好事—你的代码可是人命关天的。

然而,对于我们中的其他人,并不存在唯一正确的审核方法。最好的代码审核策略就是能带来最大好处的那个,依不同的团队和项目而不同。(提示:答案永远不是“从不审核”。)有经验的经理或技术领导应该根据需要设定策略。

不管怎样,你总是可以召集审核。当想让他人看你的代码时,只管去找,不必害羞。有经验的程序员总是这样做。若是初级程序员不请求审核,那肯定是麻烦滋生的信号。

行动指南

主动要求下次代码审核:在准备将下一次变更集检入团队的代码库之前,找位同事审核你的代码。但在找他之前,得做点功课:

1. 产生改动的文件列表。源代码控制系统应该可以方便地告诉你这些信息;一般是“status”命令。

2. 收集每个文件的差异,最好用图形化的对比工具,它会让你同时看到原始副本和当前副本,变动部分会突出显示。

3. 现在,不要省去这一步,自己整体看看变更,确保你可以解释它们每一个。我不是指的是像审查风格那样,逐行深入了解你的动机,而是寻找明显的疏忽。里面很可能会有无意间引入的错误,把它改过来,重新获取新的差异。

现在,找个伙伴。要是你的团队没有明令这样做,只要找另一位程序员(最好是比你资深的人)就行,像这样说:“你愿意在我把代码检入之前看一下我的改动吗?”

拉上你的伙伴,在屏幕上展示差异,解释你修改的目的,然后对每个文件的差异逐个审阅。可以是你或伙伴来主导,只要效果好,哪种都行。假如你的编程风格很优雅(为什么不这样要求自己呢),伙伴应该可以很快看完你的变更。

除了解释代码外,还要解释你的测试方法。理想情况下,你会有一个自动化测试套件;也审核这些代码。要是没有,说明一下你做过的任何手动测试或证明代码的正确性。

甚至在叫伙伴过来之前,你也很可能会找到一两个疏忽。此外,你的伙伴会问一两个你没有想过的问题。你可能会发现,每次提交时都需要一个检入伙伴。