Code Review是软件工程中很有意义的一个活动

Code reviews 确实有很多用处，而在实际工作中它被用来找到程序bug、保证代码风格、编码标准。过于负担了。它不应该承担发现代码错误的职责，而是审核代码的质量，如可读性，可维护性，健壮性以及程序逻辑对需求的实现正确完整性。程序中的bug应该由单元测试、集成测试、性能测试、系统测试、回归测试来保证的，其中主要是单元测试是最重要的环节，因为那是最接近Bug，也是Bug没有扩散的地方。 它不应该成为保证代码风格和编码标准的手段。编码风格和代码规范都属于死的东西，每个程序员在把自己的代码提交团队Review的时候，代码就应该是符合规范的，这是默认值，属于每个人自己的事情，不应该交由团队来完成，否则只会浪费大家本来就不够的时间。 今天，在中国的很多公司里，上面这两件事依然被认为是Code Reivew最重要的事，但在实际工作中够看到很多开发Team抱怨Code Review就是一个形式，费时费力不说，发现的问题还不如测试。对于代码规范，这应该是程序作者自己需要保证的，而且有一些工具是可以帮你来检查代码规范的。 上述言论并不是说，在Code Review中报告一个程序的bug或是一个代码规范的问题。我只是说，那并不是Code Review的意图。 如何使Code Review更有意义。 经常进行Code Review。就好像人家都把整个房子盖好了，大家Review时这挑一点、那挑一点，有时候触动地基或是承重墙体，需要大动手术，让人返工，这当然会让盖房的人一下就跳起来极力地维护自己的代码，最后还伤了团队成员的感情。所以，千万不要等大厦都盖好了再去Reivew，而且当有了地基，有了框架，有了房顶，有了门窗，有了装修的各个时候循序渐进地进行Review，这样反而会更有效率，也更有帮助。当然，在敏捷开发中，他们不需要Code Reivew，其实，敏捷开发中使用更为极端的“结对编程”（Pair-Programming）的方法 —— 一种时时刻刻都在进行Code Review的方法，个人感觉在实际过程中，这种方法有点过了。 保持积极的正面的态度。程序最大的问题就是“自负”，程序员在Code Review的时候，开始抨击别人的代码，质疑别人的能力。他们指责对方的目的是想告诉大家自己有多么的牛。无论是代码作者，还是评审者，都需要一种积极向上的正面的态度，作者需要能够虚心接受别人的建议，因为别人的建议是为了让你做得更好；评审者也需要以一种积极的正面的态度向作者提意见，因为那是和你在一个战壕里的战友。 Code Review不要太正式，而且要短。忘了那个代码评审的Checklist吧，走到你的同事座位跟前，像请师父一样请 他坐到你的电脑面前，然后，花5分钟给他讲讲你的代码，给他另外一个5分钟让他给你的代码提提意见，这比什么都好。 尽可能的让不同的人Reivew你的代码。不同的人有不同的思考方式，有不同的见解，所以，不同的人可以全面的从各个方面评论你的代码，有的从实现的角度，有的从需求的角度，有的从用户使用的角度，有的从算法的角度，有的从性能效率的角度，有的从易读的角度，有的从扩展性的角度……。当然，不要太多了，人多嘴杂反而适得其反。 学会享受Code Reivew。如果你到了一个人人都喜欢Code Reivew的团阿，那么，你会进入到一个生机勃勃的地方，在那里，每个人都能写出质量非常好的代码，在那里，他们相互学习，相互帮助，不仅仅是写出好的代码，而且团队和其中的每个人都会自动进化，这个是一个团队。