昨天的**評審，對於我個人而言，有很大幫助，在此做如下總結：
1、在寫乙個介面、類或者介面方法之前，須根據產品需求，理清思路。否則，到後期維護時會很困難。
2、在寫class或者某個方法時，試著給予明了易懂的名稱，以減少不必要的註解。
3、小心冗長的方法。冗長的方法會使方法的呼叫動作不易撰寫、閱讀、維護。應該試著將該方法搬移到更適當的類或介面中，並盡量以物件為引數。
4、不要一再重複。如果某段程式**不斷出現於許多derived class函式中，最好將該段程式**置於某個base class 方法內，然後在derived class函式中呼叫。這麼做不僅可以省下程式**空間，也可以讓修改該段程式**動作更易於進行。有時候找出此種共通程式**還可以為介面增加實用功能。
5、在建構函式中只做惟一必要動作：將物件設定至適當狀態。避免呼叫其他函式（除了final函式），因為這些函式可能會被其他人覆寫因而使你在建構過程中得不可預期的結果。
在達到以上基本的編寫規範之後，需要考慮系統的效能瓶頸的問題。
1、小心「巨大物件」。這往往是剛踏oop領域的過程式程式設計師的乙個苦惱，因為他們往往最終還是寫出乙個過程式程式，並將它們擺放到乙個或兩個巨大物件中。注意，除了應用程式框架之外，物件代表的是程式中的觀念，而不是程式本身。
2、每個類都應該有單一而清楚的用途。如果它很大，那麼它工作量過多的機會就可能很高。重新設計類的建議：
1） 複雜的switch語句：請考慮運用多型。
2） 許多方法各自處理型別極為不同的動作：考慮切割為多個不同的類。
3、盡可能的減少記憶體與資料庫或快取的互動，減少不必要的網路延遲：
1） 慎用for迴圈，盡量不要再for迴圈裡面訪問資料庫
2） 優化sql語句，能一次取出的資料不要分多次取
程式**被閱讀的時間多於它被撰寫的時間，清晰的設計能夠製作出易懂的程式，在今後的程式設計中，仍需不斷學習優秀的程式設計習慣和清晰的程式設計思路。
Code Review 之後的總結
1.對於isset和empty的區別 值isset empty a f t a 1tt a nullft array ff 2.intval變數轉成整數型別。在你確認一定是整數的時候，可以加上這個，而且在裡面可以加上號trim 例 intval trim post 3.對於錯誤值，要先判斷是否存在，...
總結 CodeReview自查要注意的點
細數過來,已經參加了不少codereview,雖有開發規約的指引，但在review的過程中，還是會有不少問題暴露出來，本文會總結在codereview之前，有哪些可以先自查的點，更好的保證 的健壯性。在codereview之前，我們先對 結構做一次剖析，開頭，我們先從最本質的物件導向說起，物件導向，...
Code Review最佳實踐
原文作者 kevin london 譯文出自 開發技術前線 www.devtf.cn 譯者 ayyb1988 校對者 chaossss 狀態 完成 在wiredrive上，我們做了很多的code review。在此之前我從來沒有做過，這對於我來說是乙個全新的體驗，下面來總結一下在code revie...