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