说说Code Review

对于软件开发团队，Code Review就如svn版本控制一样，是技术管理的常识。因为是常识，所以我们一般会这么想：如何做Code Review？在做好Code Review前，我们是否想过这样一个问题：为什么要做Code Review？

大家都知道，Code Review是基于代码规范的，代码规范是通过可读性、易修改性来解决团队协作、提升项目可维护性。这是浅层次的Code Review，更深层次的Code Review会检查技术和业务逻辑实现的正确、优雅性，类似于黑盒测试。前者可以通过工具，如Java的eclipse、checkstyle，后者如findBugs，但也只是浅层次的技术检查。

我刚开始接触Java时，就非常重视代码的规范、优雅型，完全按照Java Code Convention来，早已形成了习惯。但我发现一个有趣的现象：代码的整洁性和人的性格、行为习惯直接相关，比如办公桌比较乱的人，代码也会天然比较乱(在没有自律情况下)；水瓶座的人天性不喜欢约束，代码一般较乱，而处女座的人生性洁癖，代码通常比较整洁。
代码规范无所谓好坏，易读、团队一致认同即可，这是由它的目标(团队协作、可维护)决定的。Java和.Net的规范天然两条线，但一直做MS开发的，肯定会对Java的规范不太适应，但并不能说谁优谁劣。

如何做好Code Review？
在探讨Code Review的得与失前，不妨先谈谈如何做Code Review。
Code Review一般是由项目Leader或高级工程师做，团队内相互检效果并不好(团队内信任建立起来了吗？)。做Code Review的人，一般是对技术很感兴趣、对项目可维护性负责任的人。
Code Review主要针对公司内部项目或产品，这类产品的生命周期较长，可维护性主要是为了降低后期的维护成本(很多项目的开发和运维成本是1:5)。对于外包项目，如果做Code Review，主要是为了改进上线时的质量(客户评审)，或者承包方接管了头几年的维护。对于一次性交易的项目，在国内，大多数毫无维护性可言。
因为可维护性是需要人力和时间成本的。而且，国内的软件过程管理，还处于草莽阶段。

我的Code Review经历。
第一阶段 项目开始时，在开发工具eclipse里设置好代码检查模板(共四份)，然后和团队其它成员共享，培训如何使用。
第二阶段 项目开发到两周后，开始Code Review，将常见问题汇总，给大家一一剖析。另外还建议看一些书，如《Effective Java》、《Java Pitfalls》。
第三阶段 每周检查两次左右，持续两三周，感觉大家习惯了编码规范，我也就逐渐停止Review，从监督过渡到信任(还是会抽查的)。

代码风格从零开始养成，可能只需一个月；但如果一个人已经习惯了一种风格好几年，再改就很痛苦，这种情况必须尊重人性，就像禁烟也不是几天的事情，这很考验管理者的耐心。
良好编码规范的养成，必须要以态度(心智模式)为基础，只有认识到它的重要性，才可能真正养成；所以，对于技术经理，强调规范的重要性，远远比技术层面的强制执行，效果好得多。就如同质量管理，最核心还是一个态度和责任问题，而不是checklist。

当然了，Code Review时看到的技术能力层面的问题，是不可能几周内改进的。我推崇的解决办法是：辅导和激励，帮助他提升技术兴趣和能力。

为什么要做Code Review？
我上面已经说过了。
这里说到的为什么，可能和我的一段经历有关。从这件事，我才真正思考Code Review的取与舍。
后来项目组来了一位技术牛人，大家知道，牛人都是有性格的。不光是人有性格，而且代码也很有风格。刚开始来的那两周，我也像以前一样，进行Code Review，并且要求他遵守我们的编码规范。刚开始他还配合，后来就有些抵触，因为他就认为他写的代码很优雅，并且，我隐约感觉到他开发效率的降低，干活不太愉快。

在我们之间还没有建立真正的信任时(他认为这也有利于他)，他不太会接受我的建议：改进代码风格，用一些更stupid的实现(他的代码太过于灵活)。

那时我面临一种选择：是否该继续推行代码规范？
对商业敏感的人应该会发现，上面的提问就是错误的。真正的问题应该是：代码规范的目标是什么，成本和收益？
再退一步，我们的项目目标是什么，如何让他最大程度地达成项目目标？
问题就开始有答案了。
对于我们这种创业型公司，目前最重要的是让项目上线，接受市场的检验。

重新界定目标后，我又再思考刚才的问题：代码规范的目标是什么，成本和收益？
因为我们有几个子项目是他独立一人开发，至少在当前，不存在代码协作的问题。对于存在代码协作的地方，我在任务分配上做了纵向切割(基于模块)。当然，对于后台ERP，因为是多人开发，所以还是对代码规范要求很严。
如果让他遵守我们的代码规范，势必对他的热情和开发效率有影响(成本)，而对项目的进度和质量关系并不大(收益)。对于他负责的几个项目，如果需求稳定后，市场证明可行，重新实现的代价并不大。

其实，项目中遇到的问题，思路都是相通的。比如和这位牛人沟通过程中，发现他对代码性能非常敏感，我的看法是，对于业务系统，改进Java代码的性能，还不如改进数据库的性能(如建立数据冗余、以空间换时间)。通过技术实现改进性能，还不如改进架构和部署(如加入队列和定时任务)。我们必须先从宏观考虑在哪个层面来解决性能问题，然后才是细节层面。
我还半开玩笑地说，如果性能成为瓶颈，比如一天访问人数是10000(非常低了)，成单率是1%，也就是100，每个订单3000元，一天销售额30万，一年近一个亿，我可以再请几位技术高手，重新开发、扩展服务器。

我觉得，项目经理最重要的一种能力：如何让有限的资源(人力、资金、时间)效用最大化，也就是分析事物轻重缓急的能力。

好了，就写到这里，这篇文章只是引出一个问题，因为Code Review在项目管理中，只是一个很小的方面，像任务分配(目标管理)、会议(沟通)、工作日志(风险控制)等涉及到人的方面，比这个严峻得多。项目管理，本质上还是基于人的管理(研究人的习性和做事习惯)。

评论

43 楼 pangpang514 2011-06-30  

一般外包项目队这个倒是蛮严格的！做国内的项目，客户根本不管这个，因为客户大部分都不是技术人员，只知道想要什么！

42 楼 zwchen 2011-06-30  

poko123 写道

总是感觉很多人要把程序员的办公室弄成服装厂的生产线，作为老板可能他喜欢，但是作为程序员这是我及其反感的。 

老板可能也不喜欢，因为这都是成本。

41 楼 poko123 2011-06-29  

我还是第一次听到 CODE还可以Review，你们平常都这么空的吗，

如果像阿里这种大公司，很多人天天围绕着同一个东西闲的慌那可以试试，

像我这，一个人要做出个阿里巴巴出来似的，只有等到2.0的时候总计下以前的经验加之改进。 写过的代码从来不多看一眼，除了他不工作了。

上午要研究HIBERNATE，下面要研究LUCENE，还没缓过神来，SPRING又改版了
弄不好还得现学.NET做个小功能

我没有时间REVIEW，要是空下来不如去琢磨一些更新的思想和深入一些自己不了解的领域。再怎么REVIEW也弄不出淘宝那种排序算法，也不知道 到底PS3是怎么被破解的。


总是感觉很多人要把程序员的办公室弄成服装厂的生产线，作为老板可能他喜欢，但是作为程序员这是我及其反感的。 

40 楼 lshoo 2011-06-28  

古语有云：近朱者赤！

39 楼 zwchen 2011-06-27  

wandou 写道

如果我说的悲观的看法，不知道有没有人同意。
code review实际上无法进行。进行了也会流于形式。
真正的代码专家，代码几乎无须review。因为他的代码，始终是良好的风格，出错率很低，根本无须去review。review，对他们是个额外的负担。
而一些代码风格不良的人，仅仅是通过review,并不能让他们改正编码习惯，过一段时间就会打回原形。
真正需要改变的，不是code的风格，而是提高架构设计的水平。
代码风格不良，通常都体现在类的设计不良上。
detail design review，才是真正需要提高的重点。如果代码已经写好，设计的缺陷已经是事实，做code review又有何用？难道重头开始重做？没有多少Pm,敢承担这样的责任，最后只能走走形式，不了了之。
只有从detail design review抓起，提高硬实力，才能真正改变代码的质量。
而这个提高过程，需要的时间至少几个项目的实践锻炼。没有多少公司愿意等待，即使愿意，就软件业的实际状况看，也不是每个人都能达到要求。
所以，悲观看法，code review没用。差的还是差，好的还是好，最多，有少部分差的能渐渐变好，也不是短期能等得到的。

如果我替你重新总结一下，加一点我的看法，就是这样的：
如果需求有偏差，架构就可能坍塌
如果架构有倾斜，设计就很难支撑
如果设计已扭曲，编码就会混乱
如果编码逻辑混乱了，Code Review也不过是隔靴搔痒
当然，我这么说可能有些牵强，因为需求上模棱两可，不代表架构和设计就不清晰、优雅，一个是业务上的，一个是技术上的，两条线。但编码实现确实和需求(业务逻辑)直接相关。

就如同建一座大厦，需求是地基，架构是骨架，Coding是一种砌砖工艺。
我们必须保证在源头上的正确性，末端的Code Review才可能真正有效，比如产品开发到2.0版本了，已经接受了市场的检验，那么这时候，花精力在Code Review，回报可能会比较大。
我以前某些项目对Code Review的放弃，一个是因为团队现状，另外一个是因为需求一直不稳定(创业型项目)。

程序员的代码优雅、整洁性，别人是很难教出来的，除非他自己认识到重要性，就如同一个人的穿着打扮，只有自己觉得：有风度的男人应该有优雅外表和举止，这时候他的穿衣水平才能真正开始提高。

我记得自己的代码风格，是从看Jive Forum2.0和JDK1.4源码开始的，当你接触到的都是干净、整洁的代码，自然会拒接肮脏的东西。

38 楼 fflame 2011-06-27  

怎么感觉有些人更注重星座而不是code review呢？哈哈

个人感觉新人的代码都review一遍还是很必要的，因为看过某些代码是先查询一遍数据库存成arraylist，然后再判断是不是某种特殊情况，是的话再查询一遍把数据存成数组，当时真有种崩溃的感觉。但是这种错误是很容易发现和纠正的。
然后也是一个员工和团队融合的问题。

37 楼 wanbin021614 2011-06-27  

wandou 写道

如果我说的悲观的看法，不知道有没有人同意。
code review实际上无法进行。进行了也会流于形式。
真正的代码专家，代码几乎无须review。因为他的代码，始终是良好的风格，出错率很低，根本无须去review。review，对他们是个额外的负担。
而一些代码风格不良的人，仅仅是通过review,并不能让他们改正编码习惯，过一段时间就会打回原形。
真正需要改变的，不是code的风格，而是提高架构设计的水平。
代码风格不良，通常都体现在类的设计不良上。
detail design review，才是真正需要提高的重点。如果代码已经写好，设计的缺陷已经是事实，做code review又有何用？难道重头开始重做？没有多少Pm,敢承担这样的责任，最后只能走走形式，不了了之。
只有从detail design review抓起，提高硬实力，才能真正改变代码的质量。
而这个提高过程，需要的时间至少几个项目的实践锻炼。没有多少公司愿意等待，即使愿意，就软件业的实际状况看，也不是每个人都能达到要求。
所以，悲观看法，code review没用。差的还是差，好的还是好，最多，有少部分差的能渐渐变好，也不是短期能等得到的。

人都会犯错,几率问题,专家也是人
如果review都不能让代码风格不良的人改进错误,那么这个人KPI最后肯定很低
code review很有用,只是要看重视程度

36 楼 hobitton 2011-06-27  

wandou 写道

hobitton 写道

wandou 写道

如果我说的悲观的看法，不知道有没有人同意。
code review实际上无法进行。进行了也会流于形式。
真正的代码专家，代码几乎无须review。因为他的代码，始终是良好的风格，出错率很低，根本无须去review。review，对他们是个额外的负担。
而一些代码风格不良的人，仅仅是通过review,并不能让他们改正编码习惯，过一段时间就会打回原形。
真正需要改变的，不是code的风格，而是提高架构设计的水平。
代码风格不良，通常都体现在类的设计不良上。
detail design review，才是真正需要提高的重点。如果代码已经写好，设计的缺陷已经是事实，做code review又有何用？难道重头开始重做？没有多少Pm,敢承担这样的责任，最后只能走走形式，不了了之。
只有从detail design review抓起，提高硬实力，才能真正改变代码的质量。
而这个提高过程，需要的时间至少几个项目的实践锻炼。没有多少公司愿意等待，即使愿意，就软件业的实际状况看，也不是每个人都能达到要求。
所以，悲观看法，code review没用。差的还是差，好的还是好，最多，有少部分差的能渐渐变好，也不是短期能等得到的。

走极端了不是。

引用

而一些代码风格不良的人，仅仅是通过review,并不能让他们改正编码习惯，过一段时间就会打回原形。

悲观了，习惯是可以改的，至少大部分人是可以改的。

引用

detail design review，才是真正需要提高的重点。如果代码已经写好，设计的缺陷已经是事实，做code review又有何用？难道重头开始重做？没有多少Pm,敢承担这样的责任，最后只能走走形式，不了了之。
只有从detail design review抓起，提高硬实力，才能真正改变代码的质量。

design是应该抓的，但是并不意味着code review就应该放弃，两手抓，两手都要硬。

不要回避问题。

如果类库的结构设计就有缺陷，code review之后，发现改动的工作量很大，几乎是重做，请问你们如何去做？
如果你们缺少能够设计类库的开发人员，招聘困难，而现有的大多数开发人员，无法满足要求，需要培训一年才能达到要求，少数设计能力较好的开发人员，又没有足够的时间去完成全部工作，你们又如何去做？

你是两层意思，而我只回答了一个，你的意思是前期的design才是更重要的，如果前期的design都有问题了后续的review还有神马用处对不？所以我说的design和后续的review都非常重要，不是说谈review就放了design，这两个本身没有矛盾。

另外还有层意思是说如果review的时候发现前期的design很有问题，需要大量资源去修改，怎么办。。首先呢，code review和后续的refactor是两块东西，其实如果真出现你所描述的问题，其实换个角度想就很简单，你code review和refactor的目的是什么？最终目的不外乎保证项目能够拿到钱，同时后续的维护成本降低。依照这个思路衡量你refactor的成本是否值得就好了。je里面很多帖子都讨论过这个问题，我不过拾人牙慧。

35 楼 wandou 2011-06-27  

hobitton 写道

wandou 写道

如果我说的悲观的看法，不知道有没有人同意。
code review实际上无法进行。进行了也会流于形式。
真正的代码专家，代码几乎无须review。因为他的代码，始终是良好的风格，出错率很低，根本无须去review。review，对他们是个额外的负担。
而一些代码风格不良的人，仅仅是通过review,并不能让他们改正编码习惯，过一段时间就会打回原形。
真正需要改变的，不是code的风格，而是提高架构设计的水平。
代码风格不良，通常都体现在类的设计不良上。
detail design review，才是真正需要提高的重点。如果代码已经写好，设计的缺陷已经是事实，做code review又有何用？难道重头开始重做？没有多少Pm,敢承担这样的责任，最后只能走走形式，不了了之。
只有从detail design review抓起，提高硬实力，才能真正改变代码的质量。
而这个提高过程，需要的时间至少几个项目的实践锻炼。没有多少公司愿意等待，即使愿意，就软件业的实际状况看，也不是每个人都能达到要求。
所以，悲观看法，code review没用。差的还是差，好的还是好，最多，有少部分差的能渐渐变好，也不是短期能等得到的。

走极端了不是。

引用

而一些代码风格不良的人，仅仅是通过review,并不能让他们改正编码习惯，过一段时间就会打回原形。

悲观了，习惯是可以改的，至少大部分人是可以改的。

引用

detail design review，才是真正需要提高的重点。如果代码已经写好，设计的缺陷已经是事实，做code review又有何用？难道重头开始重做？没有多少Pm,敢承担这样的责任，最后只能走走形式，不了了之。
只有从detail design review抓起，提高硬实力，才能真正改变代码的质量。

design是应该抓的，但是并不意味着code review就应该放弃，两手抓，两手都要硬。

不要回避问题。

如果类库的结构设计就有缺陷，code review之后，发现改动的工作量很大，几乎是重做，请问你们如何去做？
如果你们缺少能够设计类库的开发人员，招聘困难，而现有的大多数开发人员，无法满足要求，需要培训一年才能达到要求，少数设计能力较好的开发人员，又没有足够的时间去完成全部工作，你们又如何去做？

34 楼 scottcgi 2011-06-27  

我也是水瓶座的，我就非常重视代码的规范
水瓶和处女的性格的确是那样

但我觉得写代码，兴趣和逻辑能力占一些权重

有些人整洁不起来是逻辑不清晰
还有就是真正的热爱写代码，就会精雕细琢
不喜欢，没热情当然就会能将就，就将就

33 楼 hobitton 2011-06-27  

wandou 写道

如果我说的悲观的看法，不知道有没有人同意。
code review实际上无法进行。进行了也会流于形式。
真正的代码专家，代码几乎无须review。因为他的代码，始终是良好的风格，出错率很低，根本无须去review。review，对他们是个额外的负担。
而一些代码风格不良的人，仅仅是通过review,并不能让他们改正编码习惯，过一段时间就会打回原形。
真正需要改变的，不是code的风格，而是提高架构设计的水平。
代码风格不良，通常都体现在类的设计不良上。
detail design review，才是真正需要提高的重点。如果代码已经写好，设计的缺陷已经是事实，做code review又有何用？难道重头开始重做？没有多少Pm,敢承担这样的责任，最后只能走走形式，不了了之。
只有从detail design review抓起，提高硬实力，才能真正改变代码的质量。
而这个提高过程，需要的时间至少几个项目的实践锻炼。没有多少公司愿意等待，即使愿意，就软件业的实际状况看，也不是每个人都能达到要求。
所以，悲观看法，code review没用。差的还是差，好的还是好，最多，有少部分差的能渐渐变好，也不是短期能等得到的。

走极端了不是。

引用

而一些代码风格不良的人，仅仅是通过review,并不能让他们改正编码习惯，过一段时间就会打回原形。

悲观了，习惯是可以改的，至少大部分人是可以改的。

引用

detail design review，才是真正需要提高的重点。如果代码已经写好，设计的缺陷已经是事实，做code review又有何用？难道重头开始重做？没有多少Pm,敢承担这样的责任，最后只能走走形式，不了了之。
只有从detail design review抓起，提高硬实力，才能真正改变代码的质量。

design是应该抓的，但是并不意味着code review就应该放弃，两手抓，两手都要硬。

32 楼 tiannet 2011-06-27  

CodeReview不但可以让代码变得规范，也有利于开发人员的成长，但是要做好确实比较困难，需要时间。

31 楼 wandou 2011-06-27  

如果我说的悲观的看法，不知道有没有人同意。
code review实际上无法进行。进行了也会流于形式。
真正的代码专家，代码几乎无须review。因为他的代码，始终是良好的风格，出错率很低，根本无须去review。review，对他们是个额外的负担。
而一些代码风格不良的人，仅仅是通过review,并不能让他们改正编码习惯，过一段时间就会打回原形。
真正需要改变的，不是code的风格，而是提高架构设计的水平。
代码风格不良，通常都体现在类的设计不良上。
detail design review，才是真正需要提高的重点。如果代码已经写好，设计的缺陷已经是事实，做code review又有何用？难道重头开始重做？没有多少Pm,敢承担这样的责任，最后只能走走形式，不了了之。
只有从detail design review抓起，提高硬实力，才能真正改变代码的质量。
而这个提高过程，需要的时间至少几个项目的实践锻炼。没有多少公司愿意等待，即使愿意，就软件业的实际状况看，也不是每个人都能达到要求。
所以，悲观看法，code review没用。差的还是差，好的还是好，最多，有少部分差的能渐渐变好，也不是短期能等得到的。

30 楼 hobitton 2011-06-26  

刚好看到一篇文章写的不错：http://www.javacodegeeks.com/2011/06/not-doing-code-reviews-whats-your.html

善于利用已有的工具，尽量采取"轻量级"的code review ,,etc…………

29 楼 int08h 2011-06-26  

说说我们Code Review的范围，估计很多人会觉得过分：
1、代码规范，所有的空格和缩进，一但不符合规划，比如if后面没有空格直接括号之类的，全部打回
2、变量命名，包括不符合规范的命名，以及符合了规范但是选取的词语不够好的，打回
3、逻辑整理，比如可以把较短的逻辑放前面的没放，正面能说明的if条件硬是取个反来写的，打回
4、注释，如果和他参与一个项目的人，依旧无法理解其中某一段代码所表达的业务，这一段代码又没有详细的注释，打回
5、还是注释，认为未来有新人进来看这代码，可能在没有注释的情况下看不懂的，打回
6、优化，只要Reviewer认为可以在不付出很大的代价的情况下优化的点，提出并请求编写者参考（参考的结果一般是采纳，除非对其他点有影响）

Code Review可以严格，但必须让所有人都明白，Code Review没通过绝对不是什么不光彩的事，不然严格的Review很可能打击人

28 楼 bevis.cn 2011-06-25  

如果找几个资深的人员做Code Review是对提高项目组成员的整体水平很有用,
如果一个组的人员,互相交叉code review还可以达到成员间磨合,使以后配合默契

27 楼 李飞006 2011-06-23  

如果没人review 你的CODE 然后拿到客户那里 不说太多就一个BUG 回来批评你写的是什么屁东西的时候， 我该说什么呢？

26 楼 zgsheng 2011-06-23  

水瓶座的人天性不喜欢约束，代码一般较乱，而处女座的人生性洁癖，代码通常比较整洁。

仁兄,看到这句话的时候我在喝水,差点喷了显示器.....
您有时间再研究一下血型和代码的关系吧.卖糕的，还有属相和代码的关系,也大可研究一下......

25 楼 shengfuqiang 2011-06-23  

看了几遍，明白了，你是一位PM，其他太深奥了

24 楼 Durian 2011-06-22  

浪费在code review时间，不如多花点钱找几个牛逼点的程序员。