1. 應用程式級別代碼壞味道 1.1. 布爾盲點 1.1.1. 由於函數使用布爾值而導致的信息缺失 1.1.2. 解決方案是將布爾替換為枚舉類型 1.2. 組合爆炸 1.2.1. 不同的代碼使用不同的參數組合來執行同一件事情的產物 1.2.2. 解決方案使用泛型 1.3. 人為複雜性 1.3.1. ...
1. 應用程式級別代碼壞味道
1.1. 布爾盲點
-
1.1.1. 由於函數使用布爾值而導致的信息缺失
-
1.1.2. 解決方案是將布爾替換為枚舉類型
1.2. 組合爆炸
-
1.2.1. 不同的代碼使用不同的參數組合來執行同一件事情的產物
-
1.2.2. 解決方案使用泛型
1.3. 人為複雜性
-
1.3.1. 簡單的架構複雜化
-
1.3.2. 解決方案務必保持軟體的簡單易懂（Keep It Simple，Stupid，KISS）
1.4. 數據泥團
-
1.4.1. 相同的欄位同時出現在不同的類和參數列表中時
-
1.4.1.1. 說明系統中缺少類定義
-
1.4.2. 識別並泛化缺失的類可以降低系統的複雜度
1.5. 粉飾註釋
- 1.5.1. 註釋中用優美的詞句掩蓋代碼的缺點
1.6. 重覆代碼
-
1.6.1. 多次出現的代碼
-
1.6.1.1. bug=技術債務=程式員支出
-
1.6.2. 解決方案將這些代碼添加到當前項目的可重用類並放置在類庫中
-
1.6.3. 解決方案2：面向方面編程（AOP）是另一種刪除樣板代碼的方法
1.7. 意圖不明
- 1.7.1. 他人無法輕易理解代碼的意圖
1.8. 可變的變數
-
1.8.1. 不同操作之間多次更改的變數
-
1.8.2. 消除變數的可變性，使其值更易於預測
-
1.8.3. 函數編程
-
1.8.3.1. LINQ
1.9. 怪異的解決方案
-
1.9.1. 源代碼中解決同樣問題的方案多種多樣
-
1.9.1.1. 源代碼中解決同樣問題的方案多種多樣
-
1.9.1.2. 沒有制定統一標準而造成
-
1.9.1.3. 程式員並沒有意識到系統中已經存在解決方案
-
1.9.2. 解決方案：不同的重覆的解決方案編寫新類，並將最整潔最高效的方式添加到類中
-
1.9.3. 解決方案2：適配器模式來統一不同的系統介面
1.10. 霰彈式修改
-
1.10.1. 一種改動需要在多個類中進行修改
-
1.10.1.1. 複雜的代碼還會導致程式員認知負擔過重
-
1.10.2. 減少耦合可以使類更易於測試
-
1.10.3. 將不屬於類的代碼移出到恰當的位置可以提高應用程式的可讀性、可維護性與可擴展性
1.11. 解決方案蔓延
-
1.11.1. 一種職責在不同的方法、類甚至庫中均被實現
-
1.11.2. 單一職責轉移到同一個類中
1.12. 不可控的副作用
-
1.12.1. 在產品中由於無法被質量保證過程發現而引起的問題
-
1.12.2. 唯一的辦法就是重構代碼使其完全可測，並可以在調試期間查看變數的狀態以確保程式的正確性。
2. 類級別代碼壞味道
2.1. 過高的圈複雜度
-
2.1.1. 大量的分支和迴圈
-
2.1.2. 1～10
-
2.1.2.1. 代碼簡單沒有風險
-
2.1.3. 11～20
-
2.1.3.1. 較複雜，風險相對較低
-
2.1.4. 21～50
-
2.1.4.1. 引起註意，中等風險
-
2.1.5. 超過50
-
2.1.5.1. 風險高，必須重構
-
2.1.6. 解決方案
-
2.1.6.1. 使用工廠模式替換switch語句
-
2.1.6.2. 改善if語句條件檢測的可讀性
-
2.1.6.3. LINQ語句替換迴圈
2.2. 發散式變化
-
2.2.1. 對代碼進行一處更改，但是發現自己必須更改許多不相關的方法
-
2.2.2. 原因
-
2.2.2.1. 類結構不良造成
-
2.2.2.2. 複製粘貼代碼
-
2.2.2.3. 利用基類和子類的關係實現繼承
2.3. 向下類型轉換
- 2.3.1. 將基類轉換為它的一個子類
2.4. 過度的字面量使用
-
2.4.1. 將字面量保存在常量中
-
2.4.2. 將字元串字面量放置在本地化資源文件中
2.5. 依戀情結
- 2.5.1. 當一個方法花費大量的時間處理類中的代碼而非自身的代碼
2.6. 狎昵（xiá nì）關係
-
2.6.1. 一個類若依賴另一個類的實現細節
-
2.6.2. 類之間不應當相互依賴
-
2.6.3. 類應當是自包含的
-
2.6.4. 類之間應該儘可能少地互相瞭解彼此的底細
2.7. 不恰當的暴露
-
2.7.1. 類暴露了其內部細節
-
2.7.2. 打破了面向對象編程的封裝原則
2.8. 巨大的類
- 2.8.1. 務必令其儘可能小巧、整潔、易於閱讀
2.9. 冗贅類
-
2.9.1. 一種並不包含什麼有效操作的類
-
2.9.2. 和其他包含相似意圖的類合併
-
2.9.3. 削減繼承層次結構
-
2.9.3.1. 理想的繼承層次是1
-
2.9.4. 非常小的類還可以考慮採用內聯的處理方法
2.10. 中間人類
-
2.10.1. 僅將功能委托給其他對象
-
2.10.2. 捨棄中間人直接和處理相應職責的類進行交互
-
2.10.3. 將其與現有類合併
2.11. 孤立的變數和常量類
-
2.11.1. 使用一個獨立的類來定義系統不同部分使用的變數和常量
-
2.11.2. 丟失其上下文而無法表達任何實際含義
-
2.11.3. 移動到使用它們的位置
2.12. 基本類型偏執
-
2.12.1. 使用常量作為欄位名稱
-
2.12.2. 不恰當地使用常量保存信息
-
2.12.3. 使用基本類型值而非使用對象
2.13. 被拒絕的遺贈
-
2.13.1. 一個類繼承自另一個類，卻沒有使用其所有方法
-
2.13.2. 考慮是否真的需要基類
2.14. 誇誇其談未來性
-
2.14.1. 一個類的功能現在不需要，但是將來可能用到
-
2.14.2. 死代碼，應當將其刪除
2.15. 命令，而非詢問
-
2.15.1. 將數據和操作數據的方法綁定在一起
-
2.15.2. 一個對象包含邏輯，並要求其他包含數據的對象提供數據以供其執行操作，則應當將邏輯與數據合併到一個類中
2.16. 臨時欄位
-
2.16.1. 不需要在對象的整個生命周期記憶體在的成員變數
-
2.16.2. 將臨時欄位及操作這些欄位的方法移動到它們自己的類中
3. 方法級別的代碼壞味道
3.1. 不合群的方法
-
3.1.1. 一個類中和其他方法截然不同的方法
-
3.1.2. 考慮該方法的目的
-
3.1.2.1. 確定哪裡才是該方法最合適的落腳點了
3.2. 無用的代碼
-
3.2.1. 現存的方法無人使用
-
3.2.2. 要識別無用的代碼並將其刪除
-
3.2.3. 構造器、屬性和變數也應遵循相同的原則
3.3. 過多的返回數據
- 3.3.1. 遠超客戶端的調用
3.4. 過長或過短的標識符
- 3.4.1. 標識符應當既能描述對象又簡明扼要
3.5. 過長的代碼行
- 3.5.1. 應儘量將其格式化，在點號和逗號處換行
3.6. 過長的方法
- 3.6.1. 方法應當只負責執行單一任務
3.7. 參數過多
- 3.7.1. 方法參數數目超過3個
3.8. 過度耦合的消息鏈
-
3.8.1. 當一個方法調用一個對象，繼而調用另一個對象
-
3.8.2. 消息鏈違反了迪米特法則
-
3.8.2.1. 類只應當和離其最近的鄰居通信
-
3.8.2.2. 重構類，將所需的狀態和行為放在距離其更近的位置
