最近一个朋友和我在雅虎上讨论关于代码审查( Code Review),摘要贴出来:
朋友 : 你们对于代码也review么?
朋友 : 呵呵。
summerfang : 很密集
summerfang : 我每个星期自己做3-4次
朋友 : 现在我碰到的问题是,有些新手的注释不规范。
朋友 : 这是要强制要求的是么?
summerfang : 代码review是个好办法
朋友 : 如果少写了,重写是么?
summerfang : 没有在所有的地方完全强制。
朋友 : 哦
summerfang : SP和EP是强制的
朋友 : 类 和 方法, 函数是强制的么?
朋友 : 哦
朋友 : 但是里面呢?
summerfang : Review有几种
summerfang : 一般性的Review
朋友 : 嗯,侧重不同是吧
summerfang : 比如,代码风格Review,适合周期性的Review
朋友 : 哦
朋友 : 你们一般是抽查,还是大覆盖面的查啊?
summerfang : Review之前通常有些通用规则,如不能Hardcode等等
朋友 : 对
朋友 : 这个是有的。
summerfang : 随机
朋友 : 哦
summerfang : 主要是针对问题
朋友 : 哦
朋友 : 知道你的意思了。
summerfang : 比如每个SP我会抽5个Bug review
summerfang : 总的来说,根据需要,做出可行的Review计划
朋友 : 哦。明白了。
summerfang : 另外,如果做了,就一定要坚持
summerfang : Code Review非常有效
朋友 : 哈哈。这个难。
summerfang : :)
朋友 : 不过,没收效前还是要坚持的。
summerfang : 我现在Review上瘾
朋友 : 哈哈
朋友 : 也能看到不少精华啊。
summerfang : 问题居多
summerfang : 对我自己也是挑战
summerfang : 很多人的代码呀
朋友 : 呵呵
朋友 : 那是
朋友 : 不够水平的看也看不出啥来。
summerfang : 还好现在问题还比较明显:)
代码审查是提高代码质量的良药。但良药苦口,也有很多问题。
首先,没有习惯代码审查的开发员的心理抵触。当指出代码中的问题时,很多程序员会感到难堪。特别是不直接影响程序功能的代码,比如,不良代码风格。另外,现在的软件开发常常是多人维护的,如果不良代码是别人写的,总感觉象代人受过一样。这时,不得不反复说明,代码审查目的是帮助找到问题,而不是将某人的军。也正是因为这些原因,很多项目负责人不愿意推动代码审查,要不,就搞得太正式。
其次,如果代码审查没有目标,则很容易使得代码审查变得很无趣,变成了程序逻辑报告会。通常,我在代码审查之前,心理尽量有一个方向,比如今天主要看代码风格,或安全问题等。这样容易找出问题。如果能在一个公共可访问的Web site写上一个检查列表,审查之前表态:今天主要审查这些条目,那会更有效。
还有,代码审查的目的是有分类的,不同的审查有不同的焦点。如:
以审查代码风格为主的审查。这种审查,适合周期性举行。
以审查程序逻辑的审查。审查程序逻辑,建议在设计之初,实现中,结尾时各做一次。
以审查特定目标的审查,如安全等。最好辅助工具,如不安全函数列表扫描等。
应该还有很多要点,暂时写到这儿。