曾经有一段垃圾代码放在我的面前，我没有拒绝，等我真正开始接手的时候我才后悔莫及，程序员最痛苦的事莫过于此！---------改编于周星星的经典台词。
虽然有点夸张，但编码界确实大大存在这种情况，每当接手别人的代码，都有一种想重新写一遍的感觉，等到别人再来接手你的代码时，同样的感觉。。。为什么会有这种现象存在？因为没有Code Review
一。前言
Code Review中文应该译作"代码审查"或是"代码评审"，也叫代码QC，这是一个流程，当开发人员写好代码后，需要让别人来review一下代码，这是一种有效发现BUG的方法。review之后，可以发现代码的风格、逻辑、思路等问题。然后改进代码,提高代码质量。因为这是代码刚刚出炉的时候，所以，这也是代码调整、代码修改、代码重构的最佳时候。所以，Code Review是编码实现中相当重要的一个环节。
二。Code Review的内容
1.编程素养
见码如见人，代码风格在一定程度上反应一个程序员的能力和素养，如代码风格、注释、变量的命名、缩进、初始值、方法的长度、流是否关闭、连接是否关闭
2.业务逻辑
代码实现的过程，就是对需求理解的一种复现，如果业务逻辑都错了，代码写得再漂亮、再牛B也是枉然
3.架构设计
业务逻辑实现了，只能给60分，代码是否具有高内聚、松耦合、可扩展的特性？是否合理设计模式？
4.单元测试
没有经过单元测试的代码，不是好代码。大多数开发人员认为，测试的环境是测试人员做的事，不然要测试人员做甚？其实不然。
单元测试是一种无价的文档，它是展示方法或类如何使用的最佳文档。这份文档是可编译、可运行的，并且它保持最新，永远与代码同步。
单元测试也是架构设计的一部分，迫使我们在设计时把代码设计成可调用、可测试，从而降低代码的耦合。自动化的单元测试避免了代码出现回归，编写完成之后，可以随时随地的快速运行测试。
5.性能
对数据结构的选择和设置是否合适？
是否采用通用的线程池、对象池模块等cache技术以提高性能?
是否选择合适的IO类或采用良好的方法以提高性能？
同步方法的使用是否得当,是否过度使用？
6.安全
是否有后门？
如果是web页面，是否有csrf、xss漏洞？
是否明文存储了用户名密码？
日志中是否打印了敏感信息？
三。review的方式
1.借助软件,软件请看第四点。
建议开发人员都安装这些插件，发现问题时及时就改了
2.项目负责人或架构师review
晚上review是最好的时机，一般没有人打扰，没有会议，我一般选择这个时候
3.开发人员两两互review
开发人员两人一组，一天一次，review当天的代码。但过于频繁，久而久之就成了过场，然并卵。。。
4.开发人员在会议室review，个人更倾向于这种
代码review最好采用小会议室，开发人员一起review，时长一小时最好，不宜过长，在开发阶段一周一次review。讲解人（开发人员）选取自己本迭代做的某个功能点，先讲业务，然后讲架构、实现过程、再讲代码，期间有问题时可以随时打断，听众提问，讲解人一一作答。个人更倾向于这种。
四。常用的review软件
在敏捷开发中，每个迭代的工作量大概在两三周左右，代码量不是很多，但是如果要项目负责人或架构师一一QC所有开发人员的代码，也是个不小的任务，所以，往往需要借助第三方工具。
1.checkstyle
这是一个代码风格的检查工具，要求过于苛刻，一般很难让所有开发人员都按这个标准来。
2.PDM
这是一个静态代码扫描工具，直接扫描java源码，可以发现很多重复的代码、未使用的代码、复杂的表达式、潜在的bug。
3.findbugs
直接操作class文件而不是源码，着重于发现代码中的bug,不注重style及format
五。注意事项
1.代码review应该在良好的气氛中进行，这不是批判大会，不应有人身攻击，应就码论码。
2.代码review的目的是提前发现问题的好时候
3.代码review可以让知识共享，是互相学习的好机会
4.代码review能防止某个开发人员单点，让更多的了解他的代码，当他请假或离职，不至于手忙脚乱，有效HA
5.代码review一定要有记录，完事后发出会议纪要给所有开发人员，限期整改，项目负责人或架构师在上线前再次review
六。后记
从开发人员来看，代码review会逐步让TA改正不好的习惯，提高编码、设计、架构能力，从而走向人生巅峰，迎娶白富美，哈哈。。。
从团队来看，能改善工作氛围、提高团队的凝聚力。
从项目来看，可以提前发现问题，减少bug，提高稳定性，不再到处救火。