前言：讀萬字詳文告訴你如何做 Code Review！ 有感，特此記錄。

為什麼要做 code review

---

我們很多人都以為CodeReview不重要，因為其他人寫的程式碼和自己的關係可能不是太大，review的時候也不會上心，但事實上這個想法大錯特錯。CodeReview和我們的日常開發息息相關，缺少了它，那你的專案就是不完整的了。程式碼，是設計理念落地的地方，是技術的呈現和根本。我們可在 review 過程中做到落地溝通，不再是空對空的討論，可以在實際問題中產生思考的碰撞，互相學習，大家都掌握團隊裡積累出來最好的實踐方式。這樣才能不斷完善系統功能的同時提高自己技術水平。

程式碼變壞的根源

---

我們在審查程式碼時，總是會出現壞程式碼，在文章中舉例了一些例子：

• 重複的程式碼
  寫程式碼我們比拼的不是行數，發現有些方法，重複用到一段邏輯，這段邏輯如果不抽取出來成為一個方法，未來的修改就成了一個必須多點全部修改的大坑，稍有不慎，容易遺漏。重複程式碼在提交行數上，似乎挺壯觀的。但是對後期運維來說是個隱患。
• 早期有效的決策不再有效
  完成一個介面不應該只是考慮實現功能，而應該考慮這個介面是否可以擴充套件，如何進行擴充套件為不斷變化的需求提供預留。
• 過早的優化
  在還沒弄清楚需求未來的變化的走向的時候，你的優化不僅可能導致你無法很好地實現新的需求，而且你對優化的預期的猜測有可能還是錯的，導致實際上你除了把程式碼變複雜以外什麼都沒得到。
  -對合理性沒有苛求
  對程式碼合理的進行嚴格規範要求，是一個優質的程式碼的基礎。
• 總是物件導向/總喜歡封裝
  不要胡亂的進行沒有設計的封裝，這會對團隊協作有很大的破壞，在一個壞的設計下進行迭代，如同地基沒有打好，樓只會越建造越趨近崩塌。
• 根本沒有設計
  設計是很重要的，你肯定不可以知道個需求就沒有計劃的埋頭瞎幹，這對後續的迭代是毀滅性的。

必須形而上的思考

---

我們必須構建起自己的技術思考'面'，進入立體的'工程思維'，把技術細節和系統要滿足的需求在思考上連線起來，把工程實踐中遇到的問題，從問題型別和解法型別，兩個角度去歸類，總結出一些有限適用的原則，就從點到了面。把諸多總結出的原則，組合應用到自己的專案程式碼中，就是把多個面結合起來構建了一套立體的最佳實踐的方案。

model 設計

一開始面對業務領域，應該思考自己的模型邊界，把可能要做的能力都拿進來思考，構建一個 model，設計一套通用的 store 層介面，基於通用介面的邏輯程式碼。當產品不斷髮展，就是不停往模型裡填內容，而不是推翻重來。model 設計，是我們形而上思考問題的一個方面，我們想要獲得這種能力，首先要去看前人的思考，站在前人的肩膀上，再用上自己的通識能力，去進一步思考，這樣，我們才可以更好的具備model 拆解/抽象/構建的能力。

常見原則

• KISS 原則：Keep It Simple Stuped
  KISS 原則是指產品的設計越簡單越好，任何沒有必要的複雜都是需要避免的。簡單不是容易做到的，需要大家在不斷的時間和 code review 過程中去積累思考，pk 中觸發思考，交流中總結思考，才能做得愈發地好，接近’大道至簡’。
• 組合原則: 設計時考慮拼接組合
  設計功能時儘可能地將其元件化，工具化，形成一個可插拔的外掛，這樣減少重複率也提高了我們複用和擴充套件性。
• 吝嗇原則: 除非確無它法, 不要編寫龐大的程式
  代價是程式碼越多，越難維護，難調整。對於程式碼，要吝嗇。能把系統做小，就不要做大。review 時，就應該最關注核心 struct 定義，構建起一個完備的模型，核心 interface，明確抽象 model 對外部的依賴，明確抽象 model 對外提供的能力。其他程式碼，就是要用最簡單、平平無奇的程式碼實現模型內部細節。
• 透明性原則: 設計要可見，以便審查和除錯
  對使用者而言，良好的文件有助於提高可顯性；對程式設計師而言，良好的變數和函式名有助於提高可顯性。作為程式設計師至少要理解自己呼叫的函式/複用的程式碼大概是怎麼實現的。而，為了保證大家能對自己程式碼能做到有控制力，所有人寫的函式，就必須具備很高的透明性。而不是寫一些看了一陣看不明白的函式/程式碼，結果被迫使用你程式碼的人，直接放棄了對掌控力的追取，甚至放棄複用你的程式碼，另起爐灶，走向了’製造重複程式碼’的深淵。
• 通俗原則: 介面設計避免標新立異
  設計程式過於標新立異的話，對程式的破壞性，簡直無法想象。
• 緘默原則: 如果一個程式沒什麼好說的，就沉默
  不要亂列印log，亂七八糟一大排的日誌只會影響排查問題，真的需要列印log時，把必要資訊給全，讓其容易理解，否則一個不知道代表著什麼的log還不如不打了呢。我們將使用者的注意力視為有限的寶貴資源，程式設計師自己的注意力也是一樣的。
• 補救原則: 出現異常時，馬上退出並給出足夠錯誤資訊
  對於程式錯誤 ，我們就必須要嚴格做到在問題最早出現的位置就把必要的資訊蒐集起來，高調地告知開發和維護者“我出現異常了，請立即修復我！”

如何實踐code review

• 對於程式碼格式規範，100%嚴格執行，嚴重容不得一點沙。
• 檔案絕不能超過 800 行，超過，一定要思考怎麼拆檔案。工程思維，就在於拆檔案的時候積累。
• 函式對決不能超過 80 行，超過，一定要思考怎麼拆函式，思考函式分組，層次。工程思維，就在於拆檔案的時候積累。
• 程式碼巢狀層次不能超過 4 層，超過了就得改。多想想能不能 early return。工程思維，就在於拆檔案的時候積累。
• 從目錄、package、檔案、struct、function 一層層下來 ，資訊一定不能出現冗餘。比如 file.FileProperty 這種定義。只有每個’定語’只出現在一個位置，才為’做好邏輯、定義分組/分層’提供了可能性。
• 多用多級目錄來組織程式碼所承載的資訊，即使某一些中間目錄只有一個子目錄。
• 隨著程式碼的擴充套件，老的程式碼違反了一些設計原則，應該立即原地區域性重構，維持住程式碼質量不滑坡。比如:拆檔案；拆函式；用 Session 來儲存一個複雜的流程型函式的所有資訊；重新調整目錄結構。
• 基於上一點考慮，我們應該儘量讓專案的程式碼有一定的組織、層次關係。我個人的當前實踐是除了特別通用的程式碼，都放在一個 git 裡。特別通用、修改少的程式碼，逐漸獨立出 git，作為子 git 連線到當前專案 git，讓 goland 的 Refactor 特性、各種 Refactor 工具能幫助我們快速、安全域性部重構。
• 自己的專案程式碼，應該有一個內生的層級和邏輯關係。flat 平鋪展開是非常不利於程式碼複用的。怎麼複用、怎麼組織複用，肯定會變成’人生難題’。T4-T7 的同學根本無力解決這種難題。
• 如果被 review 的程式碼雖然簡短，但是你看了一眼卻發現不咋懂，那就一定有問題。自己看不出來，就找高階別的同學交流。這是你和別 review 程式碼的同學成長的時刻。
• 日誌要少打。要打日誌就要把關鍵索引資訊帶上。必要的日誌必須打。
• 有疑問就立即問，不要怕問錯。讓程式碼作者給出解釋。不要怕問出極低問題。
• 不要說’建議’，提問題，就是剛，你 pk 不過我，就得改！
• 請積極使用 trpc。總是要和老闆站在一起！只有和老闆達成的對於程式碼質量建設的共識，才能在團隊裡更好地做好程式碼質量建設。
• 消滅重複！消滅重複！消滅重複！

總結

---

由於工期緊、需求變更快，如果不想清楚為什麼要做 Code Review ，遇到障礙會非常容易妥協，慢慢 Code Review 就會走樣，最終流於形式。反之，在我們遇到障礙，review 程式碼不順利時就會以積極的心態來解決問題。Code Review會影響開發效率，事實上追求高質量的程式碼本身就降低了區域性的開發效率，但是放眼長遠，這樣寫出來的程式碼更加健壯，不會或很少出現“詭異”的bug，降低了後期維護的成本。諺語曰: 'Talk Is Cheap, Show Me The Code'。知易行難，知行合一難。我們只有不斷審查程式碼的基本設計原理，設計思想，讓我們養成良好的編碼習慣，並學習優質的設計理念進行實踐才能達到知行合一的效果。