程式碼的怪味道

第一次看到這個概念，是在講敏捷軟體開發 ( Agile Software Development ) 的這本書(【敏捷軟體開發--原則、樣式及實務】，碁峯出版)中，最近在有關重構( Refactoring ) 的兩本書裡，又看到這些怪味道的描述。想起當時看到這些描述時，我的心裏可真是『點頭如搗蒜』，百分之五百的認同啊!

過去我們所寫的程式碼，忽略了分析與設計的階段，今天說，我們來做個遊戲吧，明天就開始Coding，然後遊戲程式的主架構就建立起來了，然後加上主角人物，加上地圖，加上場景，加上遊戲介面，加上各式各樣的功能與物件......

然後...程式碼就改不動了。

主角人物跟場景的關聯性太高，所以我們要加一點程式碼讓他飛行的時候，場景的程式碼要跟著修改，地圖的程式碼，遊戲介面的程式碼，也都要做修改，『牽一髮而動全身』。

這樣也還好。至少我們還知道要從哪裡開始去改。怕就怕在，程式碼的流程跟架構都難以理解的時候，我們為了修改出所要的功能，只能『挖東牆補西牆』，可沒想到，程式碼這裡少一塊，那裡少一堆。我們花了好大功夫，修修補補之後，功能是完成了，但是程式碼卻更加改不動了。

還有，不知怎麼搞的，就在一剎那間，Bug開始像瘟疫一樣擴散。好不容易在這裡修好了一個Bug，卻在別的地方乒乒乓乓冒出五六個新的問題，於是乎，Bug是越改越多，我們對自己的程式碼也越來越沒自信。

所以我們常常會說，『拆掉重做還比較快』。

但真的是這樣嗎?

如果這個程式碼可以很容易拆掉的話，我們在修改的過程中也就不會有那麼多問題了。同樣，重新做一個也未必會比較好，除非我們回頭把分析跟設計做好，否則這些問題還是一樣會發生。

治療這些問題，只能治本，不能治標。從一開始，我們就要把需求、分析、設計這三項工作做好。當然，需求絕對是會變的，尤其是遊戲專案這樣的程式。一旦需求變更，我們就必須針對這些修改的部分，再做一些分析設計，調整我們程式結構裡面不適宜的部分，隨時隨地保持整個程式碼的架構清楚，容易理解。也許這樣一來，原本三五分鐘可以做完的功能，要花掉一天的時間，但是我們所得到的，是一個一直都像重新做過一樣的程式碼，而不是一個一步步變得僵化、脆弱、難以理解、甚至Bug叢生的程式碼，誰說這不值得?

PS. 書裏面提出的怪味道，包括：
1. 僵化性 (Rigidity)
2. 脆弱性 (Fragility)
3. 固定性 (Immobility)
4. 黏滯性 (Viscosity)
5. 不必要的複雜度 (Needless Complexity)
6. 不必要的重複 (Needless Repetition)
7. 晦澀性 (Opacity)