2008年8月6日 星期三

程式碼的怪味道

第一次看到這個概念,是在講敏捷軟體開發 ( 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)

2 則留言:

PeterPan 提到...

老爺好像有不少書,可以借一些來讀讀嗎 (或是辦個讀書會也不錯,我越來越覺得自己面目可憎了... ) 。

藍斯洛 提到...

請隨時來找我借就是了。
話說,雖然最近有在看書,我也還是覺得自己面目可憎....怎麼回事咧?