文章出處：http://www.aygfsteel.com/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，我建議可以放在后面，在一般性錯誤解決之后進行，此時你對代碼也將再度變的熟悉。