代码审查的对话

最近一个朋友和我在雅虎上讨论关于代码审查（ 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写上一个检查列表，审查之前表态：今天主要审查这些条目，那会更有效。

还有，代码审查的目的是有分类的，不同的审查有不同的焦点。如：

以审查代码风格为主的审查。这种审查，适合周期性举行。

以审查程序逻辑的审查。审查程序逻辑，建议在设计之初，实现中，结尾时各做一次。

以审查特定目标的审查，如安全等。最好辅助工具，如不安全函数列表扫描等。

 

应该还有很多要点，暂时写到这儿。