程式碼的怪味道  

Posted by 藍斯洛 in

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

This entry was posted on 2008年8月6日 星期三 at 星期三, 8月 06, 2008 and is filed under . You can follow any responses to this entry through the comments feed .

2 意見

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

2008年8月7日 上午12:39

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

2008年8月8日 上午9:26

張貼留言