Bad programming practice 3

Really really complicated state machine

嚴格講起來,複雜的state machine本身不是一個問題,因為有時系統本身要處理的狀況就是這麼複雜。但是如何設計結構以致於系統本身符合功能需求,並且同時state machine又不會過份複雜,這並不是一個容易解決的問題。常常你看到程式繞來繞去,試著去處理各式各樣的情況組合,但當你仔細觀察後,你會發現實際上有很多種組合根本是互斥或是不可能發生的。那為什麼程式要搞得這麼複雜、難懂?因為他就要是搞你!我仔細觀察後,覺得有兩種可能原因。

第一種是系統設計者本身在寫的時候,一邊寫一邊發現問題,而一旦發現了在某種特殊情況下會出現的問題,就把針對那個問題的處理方式寫進去,然後繼續往前。久而久之,需要特殊處理的問題越來越多,程式也越寫越複雜,然而由於時間的壓力,他從來也沒有機會回過頭來去全盤重新檢討、思考,再次確認是否對於所有情況的處理都是必須的。意思是說,他沒有時間去想是不是可以改變一下系統的設計,用一種更優雅(graceful)的方式來解決眼前的問題,儘管他是有這個能力去改變設計的。一個公司對於這種現象的態度,絕對是這個系統能不能長時間穩定發展下去的關鍵。為什麼這樣說呢?因為一個系統要能長期穩定的發展,絕對不可或缺的關鍵是在於了解整個系統架構的人,基本上原作者如果還在的話,那事情會簡單很多,但通常大部分的時候原作者都已經不在團隊了,所以你只好仰賴後來加入的人,而後來加入的人對於原始系統能夠有多了解,很大一部分取決於原始系統的設計好壞與否,如果一開始系統的設計就複雜無比,那後來的人能完全掌握原始設計理念的機會就微乎其微,於是我們就有了第二個原因。

第二個原因就是後來的工程師在不完全了解系統運作的狀況下嘗試去解決某個特殊的問題。如果說第一個原因是先天不足的話,那第二個原因就是後天失調,而這後天失調,絕對是系統開始走下坡的關鍵。這種例子實在太多,我就不舉例了。這裡我只想談為什麼會有這個現象,也就是為什麼工程師要在一知半解的情況下去修改程式?當然系統本身太複雜、沒有任何說明文件或是工程師本身太笨都是其中的可能原因,但我認為罪魁禍首還是在於時間的壓力。常常你會發現因為deadline的逼近,工程師會被要求在時限內解決問題。可是如果你看不懂原來的程式到底在幹嘛的時候,你怎麼去解決問題?還不簡單,就加幾行程式去處理你的特殊問題不就好了?那系統裡面本來就有好幾行用來處理別的特殊問題的程式碼怎麼辦?有什麼關係,再多加幾行又不會死?於是這些處理特殊問題的程式碼就像癌細胞一樣,慢慢的擴散到整個系統,然後你就會看到一個函式二千五百行,裡面處理了64個不同的狀況。一開始你覺得加幾行程式碼不會死,但當後來你發現程式跑的其慢無比,或是在跑了幾天之後就會莫名奇妙的當掉,你就會知道整個系統已經病入膏肓,無藥可救了。

就我本身的經驗而言,解決第一個原因的方法只有不斷的review,儘可能的在不影響功能的情況簡化系統的設計,或是嘗試用各種小技巧來更清楚明暸的表示你的設計理念,像是重構程式、撰寫設計文件、統一命名規則…等,這些都會對後來的工程師有相當的幫助。而如果真的沒辦法再進步了,整個打掉重寫也是一種可能。我在前一個公司待了六年,頭兩年和另一個同事一起設計了第一代的系統,而在我離開前,我們已經在進行第三代系統的開發。當然我不是說原來的東西要全部扔掉,一切歸零,我的意思是當你體認到你不再是在維護一個舊系統,而是在開發一個新系統的時候,你會比較有勇氣與時間去大刀闊斧的做一些改變。

廣告

About Weicheng Chu

創業中,微碧愛普科技 (www.weibyapp.com) 已婚, 有一對雙胞胎兒子, 現居住在美國加州、台灣台中
本篇發表於 軟體工程 並標籤為 , 。將永久鏈結加入書籤。

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s