Bloaters

It doesn‘t need to be that big.

程式碼氣味（Code Smell）中的第一個分類：Bloaters 臃腫怪。我查了一下華文世界中目前尚未有普遍公認的正式翻譯名稱，我曾看過「虛胖的程式碼」或是「代碼腫脹」這樣的描述，但我認為這些都不足以貼合這個名詞背後的意境。或許是受到Refactoring Guru網站上的插圖影響，沒有足夠留心維護的程式碼像是哥吉拉一樣逐漸演化成虛胖腫脹的怪物形象根植在我的心中，所以我選擇了「臃腫怪」這樣的華文命名。

無庸置疑的，這或許是最普遍隨處可見的程式碼氣味，廣泛存在於幾乎每一個程式專案當中。Bloaters違反了Clean Code中的最高指導原則，同時也是Sandi曾經在RailsConf 2014中「All the Little Things」所提及，寫出乾淨程式碼最關鍵的秘訣：

Make Smaller Things. - Sandi Metz, 2014

當人們詢問Sandi如何能寫出更好的物件導向程式碼時，其中一個最棒的建議是：創造出更小的物件（make smaller things）。更小的類別，更小的方法，然後讓他們彼此所知越少越好。

通往「壞味道」的道路時常由「過於肥大」鋪成，畢竟肥大虛胖往往擺脫不了惡臭油膩的形象（？！）。而這樣的連結深層原因實則來自於人類大腦同時能夠掌握的概念上限。程式碼並非僅只是交由電腦執行，大多數的時候需要由開發者透過肉眼閱讀後理解，這兩者同等重要，甚至我個人認為後者的重要性更遠勝於前者。回歸初始，程式碼一開始就是為了讓人類能夠更方便快速地與電腦互動的產物，否則人類直接編寫「1010」便完事，不需要特意發明各種貼近人類自然語法的程式語言來與電腦溝通意圖。

人類同時間能掌握的概念是有極限的，與現代的伺服器不同，實際上沒有人真正能夠像是「多執行緒」一般的工作，每個人只能把眼前的一件事處理好，然後進行下一件事。當概念一多，人類的大腦便需要更多資源在腦中構建虛擬空間去理解複雜的結構關係與邏輯，而這樣的思維負擔往往容易造成疏忽或是錯誤。這正是為何多數的程式語言，都會有建議的類別長度上限，甚至是每行程式碼的長度上限，就是為了能夠盡可能控制腦中同時接收資訊的數量，不要超過人類負荷的上限。

如同其他氣味，Bloaters會讓專案變得很難以維護。不只讓開發者需要耗費更多時間去閱讀，同時也會讓修改程式碼的成本增加。通常來說，專案初始階段類別與方法都還算是苗條，但隨著專案年齡逐年遞增，程式碼年復一年變得臃腫起來。尤其是當開發者只關注眼前的錯誤修復與新功能實作，卻沒有以專案整體的視角去審視優化，就很可能會忽略了這些長期的隱憂。

要改善這樣的氣味，如同普遍建議的重構技巧，期望能夠一步登天是不切實際的。如同五洲製藥的理念：先研究不傷身體（現有行為）再講求效果。重構很重要的就是不能破壞現有行為，創造出更多錯誤與風險。把重構的步驟與改變切小，有助於逐步管控變化與風險，更能夠讓團隊與主管接受重構的行為。對於提交出的程式碼改動，小的Pull Requests也能更好的被檢視。

幸運的是，這系列文章正是想要仔細討論氣味與重構之間的對應關係。我相信當開發者能夠辨識出氣味的同時，就可以根據這些前人的經驗，快速得到重構的技巧與指引，不需要重新造輪，而是穩穩站在技術社群的最佳實踐上，將創造力發揮在更有價值之處。

接下來讓我將介紹Bloaters分類下的五種氣味：