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