如今，公司對軟件工程師（主要是高級工程師）最迫切的需求之一，是以迭代和增量的方式提供高質量的代碼審查。
這意味著在每次 PR 審查中，開發人員被要求反復提高即將合并代碼的質量。
在這篇文章中，我將嘗試指出開發人員在進行重構或審查時應牢記的基本原則。
讓我們逐個主題來看這些點：
#1. 命名
- 有明確意圖的命名：方法或變量名應該在查看代碼實現之前就能解釋其意圖。
- 類名應該是名詞或名詞短語。
- 方法名應該是動詞。
- 為每個概念選擇一個詞：get、retrieve、fetch 是相似的，選擇一個統一使用它。
- 使用計算機科學術語：例如，AccountAdapter 對程序員來說意味著適配器模式，如果沒有相關的計算機科學名稱，則使用面向問題的名稱。
- 使用可搜索的名稱：在 IDE 中搜索特定短語會更容易。
#2. 函數
- 函數應該小：函數越大，調試起來就越困難。
- 塊和縮進應該整潔：用好 IDE 的代碼格式化。
- 只做一件事：一個函數意味著一個任務。
- 每個函數一個抽象層次：函數應該足夠小，以便在一個抽象層次的范圍內實現。
- 從上到下閱讀代碼：應該應用逐步下降規則。嵌套函數應該在母函數之后，以便有像閱讀書籍一樣的感覺。
- 使用較少的輸入：超過 3 個輸入則很糟糕，這可能意味著函數在做不止一件事。
- 沒有副作用：函數應該只做一件事，并且應該正確地做這件事，而不對其他狀態產生不良影響。
- 沒有重復：將頻繁使用的代碼片段集中在一個地方。
#3. 注釋
- 盡量用代碼表達意圖：你的代碼應該是自解釋的，以至于讀者不需要額外的注釋。
- 好的注釋：
- 壞的注釋：
#4. 格式化
- 垂直格式化：類的大小最多 200-300 行代碼。
- 報紙隱喻：類應該像報紙文章一樣。
- 垂直開放性：類中變量/方法之間的垂直距離。
- 變量聲明：類變量在構造函數之前，局部變量靠近其使用位置。
- 依賴的方法應該靠近其實現：以便輕松地從一個代碼行跳到另一個代碼行。
- 水平密度：避免需要滾動的長行。
- 團隊規則：團隊的一致性比干凈的代碼更重要。
#5. 對象和數據結構
- 數據/對象反對稱性：
- 迪米特法則：模塊不應該知道它操作的對象的內部。
- 數據傳輸對象：具有公共變量且沒有函數的類使得數據傳輸更容易，但可能存在安全問題。
#6. 錯誤處理
- 盡可能使用異常：而不是返回 null 或錯誤標志，拋出異常。
- 在異常中提供上下文：嘗試制定良好的異常處理策略。
- 不要返回 null，不要傳遞 null。
#7. 單元測試
- TDD 法則：
- 保持測試干凈和可讀。
- 每個測試/每個主題/每個概念一個斷言。
- 測試應該是 F.I.R.S.T.：
#8. 類
- 封裝：利用面向對象編程。
- 單一職責原則：每個類應該有一個單一的責任。
- 內聚性：函數操作的變量越多，它的內聚性就越強。
- 應使用極簡主義方法。
