代碼 Review 要點

1. 做代碼 Review 的人的責任

給別人的代碼做 Review 的人(Reviewer), 他的責任不僅在于保證代碼質量, 更重要地是承擔拼盤者角色. 當編寫代碼的人未來因忙于別的項目, 休假或者別的原因無法在崗時, Reviewer 將負責接手項目, 修復 bug, 增加新功能等. 所以, Reviewer 必須為自己著想, 認真負責地進行代碼 Review, 以免日后自己接手一個邏輯不通, 代碼混亂的項目(程序員俗話說的"一坨屎").

2. 做代碼 Review 的原則性要求

首先, 做代碼 Review 前, 要了解產品需求, 并從產品需求出發, 整理自己的技術思路, 然后討論被 Review 者的邏輯, 看看是否有邏輯漏洞. 如果有邏輯漏洞, 那么必須全部打回, 因為邏輯一旦不準確不嚴謹, 后面的代碼就是在建造 bug 而不是開發功能.

3. 代碼封裝

代碼封裝的思路必須從純樸出發, 不能在第一個版本就過度設計和過度封裝, 不必做過多的抽象. 例如, 代碼要盡量展開, 代碼邏輯一目了然, 串行化直腸子, 不要跳躍, 不要回調, 只要純樸的過程式編程, 不要發明各種解析和組裝機制, 讓代碼和邏輯盡可能一一對應.

直觀和一目了然, 一般是可以很好解決問題的. 但隨著時間和業務的發展 -- 注意, 這是一個過程, 這個過程不能反過來否定純樸 -- 會導致代碼重復, 類函數過長, 這時可以開始進行函數封裝, 或者抽象出新的類來組織代碼.

封裝和目的至少有一半是為了組織代碼, 而不是為了實現設計. 所以, 先不封裝, 然后再封裝, 般到橋頭自然直, 提前量打得太多的話就變成趙本山賣拐了.

4. 代碼的放置

我們寫的代碼都不是教科書上那種簡單的十幾二十行代碼的功能, 而是多個類, 多個文件, 多個函數交叉的大量代碼, 所以代碼放在哪個文件, 哪一行都是有講究的.

原則上, 解決同一類問題的代碼應該就近放在一塊, 空間上不要距離太遠, 中間不要隔著別的邏輯. 對于 Web 應用來說, 當用戶瀏覽器訪問時會執行一段代碼處理某類問題, 同時, 異常執行的代碼(如 crontab)也會去解決此類問題, 那么, 應該把解決此類問題的代碼封裝成一個函數或者類, 然后在 Web 處理請求時調用和在 crontab 執行時調用, 而不是讓代碼出現在兩個地方, 即使是這兩個地方處理的是同一個問題的不同部分, 也應該封裝起來, 放置到一塊.

5. 注釋

代碼應該有一定比例的注釋, 特別是業務型代碼. 由于業務的多樣性, 當遇到業務邏輯不符合常理, 或者某些臨時解決方案, 某些照顧特殊, 等等不符合普世公認的常理, 但有合理理由存在的需求時, 你必須在代碼中進行注釋, 這時, 在注釋中描述業務的不合理之處, 然后說明代碼是如何就對的.

所以, 代碼中必須有注釋, 從自我的角度考慮, 要注釋那些可能變化的東西, 以免自己過兩天連自己都不認識了. 從 Reviewer 的角度考慮, 如果你不要求別人寫上注釋, 等你接手之時, 倒霉的是你自己, 而不是別人.

另外, 注釋可以解釋代碼的邏輯. "1,2,3,4" 這樣一條一條按順序地列出來, 一一對應后面的代碼邏輯塊. 如果你從來沒有寫過"1,2,3,4"這樣的注釋, 說明要么你不懂得封裝的好處, 要么就是過度封裝而喪失了過程式編程技能. 任何一個再高級的業務邏輯, 總是能找出最核心的"1,2,3,4"串行邏輯, 那些跳躍的類和函數的交叉調用, 都是為了最終的"1,2,3,4"而打造的周邊, 不是核心, 核心是過程式的, 是串行化的.

再回到代碼封裝和放置, 最核心的"1,2,3,4"那段串行邏輯, 一般不要再被打斷分散到不同的地方, 而應該讓他們在文件里連續出現, 一屏就能全部顯示, 出沒出問題有沒有漏洞一目了然.

6. 總結

做代碼 Review 的人, 責任重于權利, 應該多想想自己的責任, 不要逃避責任. 一旦你重視自己的責任, 是一個有責任心的人, 那么在做代碼 Review 的時候, 從日后負責的角度出發, 相信你自然會理直氣壯地做代碼 Review, 在代碼上線前解決未來對自己的任何不利因素.

來自： http://www.ideawu.net/blog/archives/961.html