code review 之我见

近期code review的讨论貌似很多，也来凑下热闹，说说自己的一些认识和想法。

一、常见误区

1. 在我经历过的很多团队中，貌似不少人员都认为code review是一种上级的管理手段。毕竟翻译成中文叫“代码评审

”，这又评又审的，很多人就已经开始心里打鼓了，这嘴上不说，心底里早就开始抵触上了。这种情绪下还能指望即时

的review么？

2. code review不能算是考核工具，很多管理者都会有review出一个问题，扣多少多少类似的想法，把review简简单单

的当成了抓虫子，从而造成了更多的开发人员的抵触。一review就变味成了给开发挑刺，然后升级成双方攻防战，搞得

面红耳赤，你死我活的，最后一拍两散。

3. code review也不是个人技术挑战赛，这在很多年轻气盛的开发人员中很常见，“凭什么给他看”，“他又看不懂”

是这类人经常会说的话。其实从来没有人规定过review一定要找更厉害的人，一定要找出问题来的。

4. review是每一个团队成员的事，而不仅仅是经理或者架构师的事。这在传统的开发团队里面很常见，代码开发完了

一丢，就没自己啥事了。在敏捷开发中，review应该是每一个成员自发的行为。


二、一点想法

1. 整个团队必须保持一个开放的心态，能够虚心听取他人意见，战斗的团队是指对外战斗，不是内斗。

2. 必须建立一个前提认识：代码共享，团队中每个人都能随时浏览他人最新代码。代码不是私人物品，不能敝帚自珍。

3. 明确一个观点：任何review都不是挑错，是一种相互探讨，追求更高质量，更优代码的过程，是团队共同进步的一种手段。

4. review中每个人都是平等的，没有谁服从谁的概念。每个参与review的人要有包容的心态，不是只有你的解决办法是最优的

5. 得有一个公认的代码标准，最好能持续维护一个知识库，将一些优秀的代码、历史的review经验积累起来。

6. review要经常化，每次review的量要小，最好完成一个功能就review它。一次review一整个项目任谁都会烦。

7. 提交代码的时候要写清楚，也要有点必要的注释或文档，不要让别人去猜，浪费大家时间。