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

我就是水瓶座的，我不认为我的代码很乱。

你看，又是我偏激的想法 

前不久还在部门内部做了《代码质量》的培训，如果平时写代码不养成良好的习惯，哪敢做这样的培训。
我不太相信星座，很高兴看到成都有你这样的大牛，北漂的人儿终究还是要回家的。

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

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

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

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

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

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

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

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

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

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