说说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在项目管理中，只是一个很小的方面，像任务分配(目标管理)、会议(沟通)、工作日志(风险控制)等涉及到人的方面，比这个严峻得多。项目管理，本质上还是基于人的管理(研究人的习性和做事习惯)。

评论

23 楼 wmv_txy 2011-06-22  

我的理解codereview是一个方法，不是一个目标也不是一个流程；PM应该根据项目实际情况安排如何进行coderview。
在我们公司里面，codereview已经形成一种流程，每个项目必须要进行codereview。他也会有很多的效果。但是在一些紧急的项目里面，还是没有办法保证codereview的质量的；所以PM要能够取舍。在关键的时间做关键的事情。

22 楼 jackra 2011-06-22  

zwchen 写道

我有一个习惯，在写完代码后大约几周，因为需要改进，再去review原来的代码，发现那些代码比较丑陋，于是重构啊重构...

我曾经用Flex开发过业务框架，然后基于该框架开发业务系统。因为开始对flex的不太了解(没有看到过任何公开的项目)，所以花了一个月时间大重构，然后项目其它人也跟着重构。
一个新项目，代码不写上上万行，很难发现之前的代码重用性、健壮性等有问题。

基于我的这些经历，我觉得如果一个人对自己的代码smell要求高，那么他会千方百计去改进，即使自己加班。
当然，这很不普遍，所以没有通用性，我们也不应该在项目管理中有这样的假设。但是，作为一个PM，一定要让他的团队(辅导和激励)，喜欢上自己的代码。如果一个人觉得自己和别人的代码都很恶心，是不可能改进代码质量的，即使改进，也是应付。而这，往往是Code Improve的前提。

从你的文章就能看出来。是个做实事的人。

虽然有些时候观点有点非主流，但实际上来说，更加直接和精确。
很多主流的观念都是浮于形式，而对于项目和团队本身或许就是一些浮于虚表的负累。这样的现状其实是可以理解的，一个在基层混乱3-5年的人，就想着不断的攀升自己的薪资和职位，总要有一些相应的东西来标榜自己的光鲜。于是一大堆的国际上的主流思想进入进来，被这些人拿来做美化自己的美容剂，在自己还没想明白这些管理到底在针对什么问题的时候，就盲目的进行推行，还一边要显示自己的权威性，导致很多的规范和规约这样的东西，不仅仅很大程度上不能对开发产生积极的作用，还让很多开发消耗更多的资源。然后一旦项目出现问题，这些人还可以拿着规范说事，在执行规范的过程中什么什么地方不行，或者完全的执行力规范，最后出来问题，都是底下人的问题。哇哈哈哈哈。不知道多少技术人员因为这些不学无术的家伙“被态度不端正”了多少回。
其实很多技术人员的黑锅，都是被这些所谓的不学无术的领导人员扣在头上的，真实可悲可叹啊，多少技术人员在后期被迫无奈的转型远离自己喜欢的代码只为摆脱黑锅陷阱。真实悲哀。

你的文章，关于项目和技术的感触，很多地方有所共鸣。估计没少被喷吧。哈哈。

知识是可以学出来的，智慧只能是想出来的。

21 楼 Durian 2011-06-20  

zwchen 写道

我有一个习惯，在写完代码后大约几周，因为需要改进，再去review原来的代码，发现那些代码比较丑陋，于是重构啊重构...

我曾经用Flex开发过业务框架，然后基于该框架开发业务系统。因为开始对flex的不太了解(没有看到过任何公开的项目)，所以花了一个月时间大重构，然后项目其它人也跟着重构。
一个新项目，代码不写上上万行，很难发现之前的代码重用性、健壮性等有问题。

基于我的这些经历，我觉得如果一个人对自己的代码smell要求高，那么他会千方百计去改进，即使自己加班。
当然，这很不普遍，所以没有通用性，我们也不应该在项目管理中有这样的假设。但是，作为一个PM，一定要让他的团队(辅导和激励)，喜欢上自己的代码。如果一个人觉得自己和别人的代码都很恶心，是不可能改进代码质量的，即使改进，也是应付。而这，往往是Code Improve的前提。

ms有点道理，可是在交付测试之前做这些，千万不要开始几轮测试之后做重构，会影响代码稳定性。

20 楼 胡一刁 2011-06-20  

代码风格和基本素质有一定的关系，和所谓的星座有关系吗？
你有没有用心的在做事，这是很关键的，其它的都是借口！

19 楼 zwchen 2011-06-20  

我有一个习惯，在写完代码后大约几周，因为需要改进，再去review原来的代码，发现那些代码比较丑陋，于是重构啊重构...

我曾经用Flex开发过业务框架，然后基于该框架开发业务系统。因为开始对flex的不太了解(没有看到过任何公开的项目)，所以花了一个月时间大重构，然后项目其它人也跟着重构。
一个新项目，代码不写上上万行，很难发现之前的代码重用性、健壮性等有问题。

基于我的这些经历，我觉得如果一个人对自己的代码smell要求高，那么他会千方百计去改进，即使自己加班。
当然，这很不普遍，所以没有通用性，我们也不应该在项目管理中有这样的假设。但是，作为一个PM，一定要让他的团队(辅导和激励)，喜欢上自己的代码。如果一个人觉得自己和别人的代码都很恶心，是不可能改进代码质量的，即使改进，也是应付。而这，往往是Code Improve的前提。

18 楼 jackra 2011-06-20  

很多时候，项目是否在后期陷入泥潭。取决于前期对于细节问题的考虑深度。

我个人不太建议在写代码的过程中，过分的强调注释的覆盖度。很多时候，代码不是一次就调通的，甚至一些时候，在代码完成后，要对实现方式进行修改。这个时候，有多少人会在修改代码的过程中，修改注释呢？那么有时候我们看到的代码，可能是1.5版本，而注释是1.0版本，这个时候，注释没有起到帮助的作用，甚至有时候会成为误导。

code review。有时候或许可以把对文档整理，文档修撰结合起来。

当然最终还是要说：对于新入行的人员，不论如何强调代码的规范性，都不过分。最少在开始的短时间内，要养成他们的习惯。

17 楼 macmaoer 2011-06-19  

Code Review的出发点是应该在团队内部高度统一的，这样才能在实施过程中不至于流于形式，才能纠正技术、业务问题，才能在Code Review中提升团队成员的编程风格

其实我觉得Code Review的最终产出，也是最有效的产出应该是团队成员的成长

16 楼 Teok 2011-06-19  

最近在做code review的工作。两万多行的改动，涉及大小功能点也有十几个。

我们的pm，找了5个人去review，其中2个架构、3个高程，reivew期是十天。最近这项工作也接近尾声，我作为开发方面的负责人，我的感觉是，有点浪费。虽然，可以review出一些问题，但都不是那种伤筋动骨的，例如修改格式、copyright、变量名、删减多余空格等等，但这些事情，我们开发这边两个人，前后改了好几天，其中为此还加班三次。可能对于一个不用考虑生存问题的公司来讲，他们看重流程和规范，但是从我之前经历的中小公司来看，这种力度的review，代价太大，承担不起。
另外，代码管理工具应该也足够的好，例如我们现在用gerrit去管理代码。
code reivew在我感觉应该是一次补漏行为，它本身就有局限性：如果严重的问题在这个时候才暴露出来，那是不是应该反思前面的阶段。

15 楼 sysutyphoon 2011-06-17  

我觉得星座的说法完全扯淡，虽然我信星座。水瓶座的人注重设计，代码一般很好的；处女座的人神经兮兮，想法诡异，别人都认为是规范，他非要玩个性化，代码反而很不能让人接受。当然我这也是扯淡。这之间的关系，不是你说的那么简单。

14 楼 can4you 2011-06-17  

引用

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

水瓶座的我不知道，但是处女座的，我却深有同感

13 楼 zwchen 2011-06-17  

locked 写道

“比如和这位牛人沟通过程中，发现他对代码性能非常敏感”
这种拿着锤子看什么都是钉子的，怎么能算牛人。

你应该理解我指的牛：算法功底。

12 楼 locked 2011-06-17  

“比如和这位牛人沟通过程中，发现他对代码性能非常敏感”
这种拿着锤子看什么都是钉子的，怎么能算牛人。

11 楼 nighty 2011-06-17  

一定层次的Code Review是很有必要的，但是不能过于苛刻，像以前的项目组老大原先是做.Net的，居然为了一个方法开始的大括号是跟在方法名后面还是一下行开始跟我纠结很久。还有变量取名，String sql = xxxx，他硬是要改成String sSql = xxxx

10 楼 lavafree 2011-06-17  

做code review，同一块代码最好同一个人做，这样可以根据svn的更新做，比较快速。
当然，做代码规范的最好了解业务，不但可以找到代码问题，也可找到业务逻辑问题。
还有是可以对核心代码做code review

9 楼 seemoon 2011-06-17  

楼主说的code review大多只涉及到格式规范方面，其实code review的作用远不至此，对软件开发、质量、甚至开发者都有不可小视的意义。

软件作为意识流的产物，带来了很多不确定性，除了形式去约束可以缓解不确定性外，其实更有效果就是去改变编程者的习惯，甚至塑造编程者的编程“性格”，code review能够达到这个目的。

软件开发一直要跟代码“坏味”进行斗争，只有进行code review才能做到这一步，一旦code review终止，坏味必然出现，并且积累，因此我不同意楼主说的，在某个阶段，可以终止code review。

当然，你可以说从成本考虑，把code review割掉，但其实code review的成本会是多少？我认为比做单元测试的成本要小很多，而且要看code review采取的措施。一天花半个小时在项目中进行交叉review，非常值得。当然，可以质疑交叉review的效果，毕竟跟review人的水准相关，这要看项目leader的办法和功力了，不是一天两天的事情。

持续code review，持续改进，不仅软件，还有人，都能得到提升。

8 楼 sarstime 2011-06-17  

就你举的例子来说，目标不同，确实可以稍微放松下代码规范。但如果是大型团队，一个长期的项目，规范还是比较重要，需要重视的。

7 楼 rubys 2011-06-17  

之前的项目也做过几次 Code Review，不做的原因是：项目组成员参与的积极度不高，效果也不是太好。说到代码规范，我感觉可能每个人在开发的过程会形成一些自己认为比较满意的风格吧（有可能是自己总结，有可能团队形成的），一般新人进来的时候，要是想让他适应目前团队的规范，可能得需要一段时间的磨合，磨合结果：一种慢慢适应，另一种不适应就会选择离开（如果项目中代码的又比较乱的话，而这位新人又对代码的简洁性看的又比较重要，结果就是新人走的可能会比较大）

6 楼 fengjia10 2011-06-16  

    其实写程序也是需要天赋的，从最初的功能实现，到后来的高可读性，再到最后的代码效能的提升，是需要时间积累的，除了自己高标准，严要求外，好的代码Review机制还是有的，国外的开源软件是怎么Review的？（结队，2个或者3个）我觉得还是有借鉴意义的，在今天这个节约成本的中国，大多数公司的做法是稀疏的人力加工具，人力和个人能力参差不齐，我们暂且不说，怎么个工具发呢？团队内部制定编码规约，然后。。你懂得，最后就是让CheckStyles，PMD之类的静态代码框架去帮你实施吧，如果不行，希望你能研究下Sonar2.8，也许会有眼前一亮哟！

5 楼 Durian 2011-06-16  

软件工程不是读了基本相关的书，机械照搬就能实施的好。
更重要的是在实践中，不停修正，总结，经过几年，几轮项目的洗礼。
形成的适合自己团队的东西，paper上的铅字不值钱。
纸上谈兵只会损兵折将。

4 楼 dingzhaoxu 2011-06-16  

编码规范的确不能规定得太死，要根据公司或项目的情况而定。
关于这方面的问题，建议看下《代码大全》。