极限编程里提到结对编程和代码Review,凡是稍微懂编程的人看了都会赞成。这也体现了代码Review的重要性和必要性。但是，在实际的执行过程中，代码Review往往很难得到很好的执行。主要原因可能包含以下几点：
（1）对自己编写的代码的不够自信，害怕别人找到问题；
(2) 对于自己的编写的代码过于自信，不觉得需要代码Review；
(3) 对于自己的代码过于封闭，不愿意与别人分享代码编写经验，害怕教会徒弟打师傅；
做代码Review主要考虑：编码的规范、系统架构相关的规范、文档的规范和业务逻辑的一致（即能否满足业务需求）。有了这些，系统的整个开发的质量和代码的质量会上一个新的台阶。
从编码的规范方面，经过查询资料，总结了下列注意事项：
（１）是否符合代码格式化标准（主要参考Sun代码格式化标准）
（２）是否有多余的import项 （如果多余，会耗费多余的资源）
（３）是否定义了多余的field
（４）是否定义了多余的本地变量
（５）是否定义了多余的私有方法
（６）是否有可以重构的逻辑重复的代码 （如有，需要重构）
（７）方法／成员的public/private/static/final属性是否合理
（８）调用静态常量是否使用类／接口名
（９）是否所有实现了java.io.Serializable接口的类都有serialVersionUID （这个感觉很重要，曾经碰到过这样的问题，中间件服务器上的类和本地的类的编译的版本不一样，则报错，实现了Serializable则无此问题）
（１０）类／接口／变量／参数名，命名是否规范
（１１）所有的if,for,while块内容是否都用{}
（１２）是否有功能复杂的语句
（１３）将url，文件路径等写死在程序里（硬编码，应用静态常量或Properties文件）
（１４）将中文写在程序里 （应用Properties）
（１５）系统中使用到的非描述性字符串是否使用常量
（１６）系统中使用到的数字是否使用常量
（１７）常量是否有详细的注释
（１８）程序中是否存在System.out,System.err及Throwable.printStackTrace()
（１９）系统中打开的流／文件／连接等是否保证能正常并及时关闭
（２０）在输出日志时，低级别的输出一定要判断isXXEnabled
（２１）在生产环境中输出大量调试日志
（２２）注意使用对象的线程安全
（２３）大规模的string组装
（２４）递归方法的使用－－－尽量避免
（２５）本地线程对象是否导致memory leak
（２６）应用代码中严格禁止硬转 编码，只能在框架里做统一的处理
（２７）是否编译过正则表达式,是否有大规模的表达式
（２８）在出错路径上是否所有的资源（数据库连接，文件锁等）和引用都已经释放
（２９）在保证线程安全的同时，要注意避免过度使用同步，导致性能降低
（３０）同步对象上的锁是否按相同的顺序获得和释放以避免死锁，注意错误处理代码
（３１）所有的循环是否优化
（３２）如果调用了阻塞方法，是否考虑了保证性能的措施
（３３）方法（函数）方面检查安全
----代码是无私的，互相提高，互相进步，才是整个Team的进步和系统开发质量的提高之根本。
摘自：http://blog.csdn.net/gideal_wang/archive/2010/06/02/5643480.aspx