膨脹者（Bloaters）
我們要探討的第一類程式碼氣味是膨脹者——這是你在任何程式碼庫中最常見的跡象之一。膨脹者直接違背了 Sandi Metz 在她的演講「All the Little Things」中強調的 Clean Code 基本原則：
讓事物變小。- Sandi Metz, 2014
當被問到編寫更好的物件導向程式碼的最佳方法時，Sandi 的建議很簡單：讓事物變小。讓類別更小，讓方法更小，並讓它們盡可能少地了解彼此。
為什麼大小很重要
大小可能是邪惡的，而這個限制來自人類大腦。程式碼不僅是為了讓電腦執行——它也是為了讓開發者閱讀。人類一次能處理的資訊和概念數量是嚴格受限的。
不像伺服器可以運行多個執行緒，開發者在心理上無法做到同樣的事情。這就是為什麼遵循檔案長度和行數的指導方針對可維護的程式碼至關重要。
膨脹者的本質
膨脹者使軟體難以處理。它們代表那些已經增長到太大而難以閱讀和維護的程式碼片段。
通常，膨脹者不會一夜之間發生，而是隨著時間累積，伴隨著程式碼庫的增長。這通常是一個緩慢的過程：
- 程式碼開始時很小且良好隔離
- 新功能逐漸被添加
- 程式碼變得更通用以處理邊緣情況
- 沒有開發者指出日益增長的問題
- 最終，程式碼變得難以處理
好消息是？如果你能在你的組件中識別出膨脹者氣味，你可以用同樣導致問題的漸進式變更來讓你的程式碼更乾淨。
膨脹者的類型
過長方法
一般來說，任何超過十行的方法都應該被懷疑。它可能負責比應有的更多任務。
關鍵指標：
- 方法超過 10 行以上
- 一個方法中有多個抽象層次
- 複雜的條件邏輯
- 需要滾動才能看到整個方法
過大的類別
一個包含太多欄位、方法和程式碼行數的類別。根據經驗，超過 500 行的類別值得懷疑。
關鍵指標：
- 類別超過 500 行以上
- 多個不相關的職責
- 方法之間的低內聚性
- 難以理解類別的主要目的
基本型別偏執
過度使用基本資料型別（字串、整數、布林值）來表示應該是物件的概念或實體。
關鍵指標：
- 對所有東西使用字串（ID、狀態、類別）
- 魔術數字散布在整個程式碼中
- 基本型別值的複雜驗證邏輯
- 缺少特定領域的行為
過長參數列
當一個函式或方法有太多參數時，使其難以理解和使用。
關鍵指標：
- 方法有 4 個以上的參數
- 布林旗標作為參數
- 應該分組的相關參數
- 難以記住參數順序
資料泥團
總是一起出現並應該被轉換為自己物件的變數群組。
關鍵指標：
- 多個方法中相同的參數群組
- 總是一起傳遞的變數
- 沒有封裝的相關資料
- 重複的參數模式
膨脹者的人力成本
膨脹者創造了幾個問題：
- 認知超載：開發者花費更多心力來理解程式碼做什麼
- 生產力降低：更多時間用於閱讀和解讀而非建構功能
- 增加錯誤：複雜的程式碼更難推理和測試
- 維護性差：變更變得有風險且耗時
- 團隊摩擦：新開發者難以理解和貢獻
漸進式解決方案
處理膨脹 者程式碼氣味，如同大多數重構，最好一次一小步完成。關鍵是：
- 識別氣味 - 識別特定的膨脹者模式
- 選擇正確的重構技術 - 每個氣味都有經過驗證的解決方案
- 做小的、漸進的變更 - 避免大爆炸式重構
- 持續測試 - 確保行為保持不變
- 重複這個過程 - 逐漸提升程式碼品質
預防勝於治療
雖然我們會探索每種膨脹者類型的特定重構技術，但最好的方法是預防：
- 程式碼審查 - 在膨脹者成長之前捕捉它們
- 定期重構 - 不要讓技術債累積
- 清晰的編碼標準 - 建立大小限制和指導方針
- 自動化工具 - 使用 linter 和度量工具來及早發現問題