关于代码复查（Code Review）

[xuzhl]

这几天，我们项目组的主管叫我写一个如何做好代码复查规范和流程出来（在项目组试用）。于是上网找了好多资料，可是都是理论性的东西，实际经验的总结太少了。不知道各位大虾们能否就这个问题，发表一下自己的意见，大家讨论一下。因为，我们很多时候发现自己的代码功能实现了，性能也可以，但是代码书写的质量却常常被忽略。尤其对于一个比较年轻的项目组而言，这样的问题更是明显。
或者，大家有什么好的资源和连接可以提供给我，这里先谢谢大家了。

[stonespace]

人性的弱点，不希望别人指出自己的错误。所以审察者威望不够，容易导致愤怒。

[asj]

weinberg的《走查、审查与技术复查手册》
应该相当不错，虽说我还没来得及读，但是从看作者其他的书可以推断出这本书的质量

[ozzzzzz]

最好的Code Review方法是XP中的结对编程。但是这种方法很多人不习惯。
我想可以退而求其次，那就是倚仗单元测试。我下面大概讲一下操作的方法。
审察者不必去研究代码的细节（当然他们如果愿意，并且不会耽误进度也可以去作），他们只需求对于代码的结构有把握就可以了。这个时候他们去检查的是代码编写者的单元测试是不是完备和正确，并且按照设计要求的思路，添加那些被编码者遗漏的单元测试。这是对于代码缺陷和错误的解决方法。
对于代码中是不是遗漏了注释，我只能提供java下的解决方法，但是Cpp和别的语言你可以自己设计专门的程序去作类似的工作。javadoc是一个很好的生成代码说明文档的工具，而且掌握也很简单。你可以用它来生成代码的说明，然后检查看看说明方法和类没有被说明，那就是遗漏的注释。
代码的格式问题，不应该通过Code Review来解决。你应该命令大家使用编辑器的格式命令来设置，比如有些人认为tab应该是4空格，有些是5空格。那么你就要求他们只能使用tab，而不能去直接输入几个空格。然后你可以使用不同的观感的编辑器检查他们是不是格式清晰。
代码复审关键不是流程，而是选择合适的方法。
你们的项目组管理者有问题，这个问题应该是他自己解决的。至少他应该告诉你大概的思路。

[xuzhl]

但是，很多时候，如果项目组里面的人员比较多的话，那么很可能每个人有自己不同的编码风格。那样，我们交给客户的代码将会是什么样子是难以想象的。很多时候，开发人员的经验也不是很足够，Code Review是否可以帮助他们快速的学习到有经验的开发人员的经验呢？

。

[ozzzzzz]

“但是，很多时候，如果项目组里面的人员比较多的话，那么很可能每个人有自己不同的编码风格。”
这正是我喜欢的，其实这根本就不是问题。而且网上有很多保持代码格式化的工具，不行你们就自己写一个，这也不是困难的工作。利用工具解决格式问题，比你去硬性规定大家统一规范要代价小的多，也有效的多。比如你可以看看checkstyle这个东西，开源的软件。
Code Review是一种互相学习技术的好工具。比如你使用我的单元测试推动的方法，检查者修改了或者添加了单元测试，出现了新的bug，那么他肯定会自然的想一下为什么会这样，并且和编码者一起找问题。当然他也可能不这样作，但是无所谓。其实就只考虑单元测试是不是完备和正确就很能促进人的水平长进了。因为要做到这一点，就必须对整体和细节都有掌握和直觉才可以。而这只是我从审察者的角度去说明问题，被审察者无疑是得到帮助最多的人。

[ozzzzzz]

stonespace(stonespace)
即使威望够了，一样可能导致愤怒。
所以你看我为什么要提出使用单元测试的方法来作这个工作，就可以知道我的苦心。
事实胜于雄辩，但是也有写人不愿意见到事实。而这个时候需要一个中立的标准，虽然你可能不高兴，但是标准在那里放着，还是可以起到一定的作用。而直接去看源码挑毛病的做法，我首先认为效率是一个问题，而且最后没有具体的测试证明还是不行。