为何开发人员不愿意进行代码检视(转)

为何开发人员不愿意进行代码检视

【CSDN编译整理】据调查显示，代码审查工作有助于提高软件开发质量，然而许多开发者却不愿意在他们的团队中实施代码审查工作，本文主要分析了开发者为什么会抵制代码审查工作的原因以及为什么他们会有此想法，目的是为了引导开发者加入代码审查工作。

代码审查究竟是什么样的工作呢？通常情况下它是指否决质量的一种过程。大量统计数据表明代码审查极大的提高了软件质量以及降低了技术风险，不仅如此，它还降低了开发成本。

一起来看下代码审查工作所带来的好处：点击可查看大图

如图所示，代码审查工作带来这么多的益处，那为什么还有一些开发团队拒绝这一做法呢？我们一起来分析下原因：

文化问题或许已成为一种巨大的障碍，大部分开发者会厌恶代码审查是因为他们无法忘记那些痛苦的审查会议，更槽糕的是，他们害怕因劣质代码而遭到管理者的批评与指责（这个通常是管理者自身的原因，而不是坏代码）。代码审查工作有助于提升团队自身能力，我们应该持积极态度，而不是为了找机会来贬低同伴。

另一种可能性，当大家相互协作、积极互动时，管理者会误认为大家在“聊天”。敏捷性团队已经意识到快速创建软件工作需要积极的互动与协作。他们认为坚持代码审查工作，是通向成功的秘诀。

第三种可能性误解，开发者利用静态分析工具来查找bug，以致代码审查工作成为不必要性。然而事实并非如此，Capers Jones，一位软件质量度量领域的巨人，曾发表过一篇文章“结合视察、静态分析和测试能消除影响效率缺陷的95%”，这种三叉戟式的方法最能确保软件质量。

静态分析只是其中的一个分叉。

静态分析工具有着很大的局限性，包括无法辨认出一些疑似代码，比如，静态分析工具不具备标记功能，因为它无法确定一个函数名为getRandomNumber是否应该总返回相同的值（with a hat tip toXKCD）。

Int getRandomNumber()
{
return 4; //chosen by fair dice roll.
//guaranteed to be random
}

也许代码审查最大障碍是恐惧。开发者担心错过最后期限，害怕分心，害怕投入过多时间。要知道，这些都是愚蠢的想法，代码审查的目的是在前端开发过程中最大限度的提高代码质量以及帮助你缩短开发周期。

最后，我认为，调用一个进程（代码审查工作）能够促进团队合作，提供指导且有助于技能的发展，鼓励开发者熟悉代码的基础部分，最终可达到提高整个软件质量。当然，如果您想快速输入代码，可以考虑一些代码审查工具，前提是，你要确保该工具是轻量级并且有趣。一旦你习惯了使用该工具便有了依赖性（许多使用代码审工具用户都这么认为）“我们无法想象没有编码工具的日子”，我想你会发现它们的价值所在。

无论如何，请记住，拒绝代码审查是不可取的。

 

 

 

 

优秀的评论也转一下：

还少了几条更重要的：
1.代码检视必须要先去理解被检视人代码的需求，才能发现功能性问题，这个过程是很痛苦的
2.代码检视是需要有一定经验的人参与，而一定经验的人，往往都是去做其他事情了，牛仔很忙 

----------------------------------------

这两点的确是存在，第一点我也思考过，我们往往是一个人的实现了某个迭代交付之后，找个人来，说一天或者两天内要检视出多少多少个问题，实际上因为交付功能的人员和代码检视人员在代码实现过程中没有任何交流，导致来检视代码的人很难搞清楚这些代码的逻辑实现，也就很难检查出掩藏比较深的逻辑问题，而这些问题是最需要检查出来的。对于那种数千行的迭代交付，就更难被检视了

目前应该将一轮迭代中的检视也分为若干轮，比如可以按照500行一次检视，这样来搞，每天代码实现者要花20分钟向检视人员讲一下他今天实现的代码内容，然后检视者每天增量检视，这样检视者和代码实现者每天实际上都在交流，问题也可以及时发现，在下次检视前修改完毕

而检视输出和根据检视的改进一律算工作量，给出整改的时间和人力，不要单独冒进追求迭代交付速度，否则欠账到后面会以更高的成本偿还

可以写两部分代码的人交叉对对方做这种检视，这样检视的过程中既发现了问题，又相互学些了代码实现和业务知识，后续也不用专门搞技能传递的培训（专门培训效果也不好）

----------------------------------------

实际推动起来很困难，实践过很多次，特别是合作方，很难做到位，依赖于两个人的责任心，并且增量检视费时费力，有的开发者可能自己都没开发完，头疼的很，就不愿意去检视别人的代码，总之检视代码推行困难，效果没理想中那么好

----------------------------------------

呵呵，感觉检视还是很重要的，或者将功能按照功能复杂度和技术风险度排序，然后在人力和资源有限情况下，保证复杂度高和风险大的可以得到优先检视

并且检视结果统计不要只算检视发现问题个数，要将检视发现的问题归类，然后鼓励发现逻辑类问题和影响程序稳定性的问题