文章出处：http://www.blogjava.net/killme2008/archive/2010/05/18/321219.html

1、首先态度需要端正，做代码的自我审查并不是否定自己，而是给自己将工作做得更好的一次机会。在审查过程中要尽量将自己作为一个旁观者的心态去审查自己的代码，尽管这比较困难。

2、代码审查离不开重构，在审查过程中发现任何坏味道都请使用重构去改善，发现缺乏测试的地方要及时补充测试，不要让BUG遗漏。

3、代码的自我审查可能不是越早越好，隔一段时间之后回去看自己写的东西，对一些设计上的选择能有更客观的评价，在审查的过程中可能需要重新去理解代码，在此过程中可以检查自己代码的可读性，并思考如何改善可读性，切记代码首先是给人读的。

4、审查过程中需要记录下一些犯下的错误，以及当时为什么会犯下这样的错误，建立自己的bug数据库，并时常review，在以后的工作中避免同样的错误。

5、代码的自我审查应该是一个持续性的过程，而非特定时间的特定行动，时常审查自己的代码，不仅能辨析自己的得失，还能够进一步提高自己在未来工作中的设计能力和预见能力。

6、代码的自我审查跟团队成员之间的相互review并不矛盾，在相互review之前做一个自我审查，有助于提高review的效率，包括可读性的提高和一些一般错误的避免。

7、代码自我审查的一些常见注意点：
（0）自认为绝不会出错，并且从来没有审查过的代码。
（1）注意else语句，if条件下的子语句通常可能是个正常的流程，而else意味着异常的情况或者特殊的场景，你可能特别注意怎么处理正常的情况，却忽略了else子句的实现细节，如该释放的锁没释放，该递减的计数没有递减，该赋予特殊值却没有赋予等等。
（2）注意空的方法，没有方法体的方法，是不需要实现？还是忘了实现？
（3）注意switch语句，有没有忘了break？这种错误通过findbugs之类的静态代码检查工具都能避免。
（4）注意大块的注释，为什么这么多注释？是代码写的很糟糕？还是遗留的注释？遗留的注释会误导人，要及时删除。
（5）注意一些看起来“不合常理”的代码，这样的代码很多都是基于所谓性能考虑而优化过的代码，这样的优化是否还需要？是否能去除这些“奇怪”的代码也能实现正常的需求？
（6）对客户端的使用有假设的代码，假设用户只会这么用，假设用户只会用到返回对象中的某些属性，其他属性一定不会用到？不要对客户代码做假设！这个客户代码包括外部用户和调用这个模块的内部代码。
（7）标注了FIXME、TODO之类task标签的代码，是否忘了修复BUG，实现功能？
（8）任何超过15行以上的方法，这些方法是否能拆分成更细粒度的方法，并保持在同一个抽象层次上？
（9）任何在代码中出现的常量值，是否应该提取出来成为单独的常量，常量的默认值设置是否合理？
（10) 任何持有容器的代码，提供了放入容器的方法，是否提供了从容器中移除对象的方法？确保没有内存泄漏的隐患。
（11）重构中提到的其他坏味道，别放过它们，但是也不要追求完美，OO不是圣杯，如果能简单的实现一个算法，你不要引入3个对象和4个接口。
（12）在review最后能列出一张清单，开列下该项目面临的风险点，并提出解决办法，然后按照这张清单去review关键代码，着重检查异常情况下的处理。风险点的review，我建议可以放在后面，在一般性错误解决之后进行，此时你对代码也将再度变的熟悉。