星期一, 7月 28, 2008

重構不是萬靈丹

若是公司資訊主管,又沒有公用的源碼 repository,請你就別往下看了。

上星期看到Q大 程式碼共有下的團隊開發 馬上就轉寄給主管看。

其實Q大寫得很客氣,一間公司的系統沒有明確的code conventions,又不推動code share,只是讓這個系統綁死在某個programmer手上。

就算這個高手再強,品德再好,他總有一天會因為業務關係而不得不把舊系統交由他人維護。拿敝公司來舉例,VB超人和鳥毅交情好,他寫的程式也很簡捷,但是風格差異實在過大。當鳥毅接收VB超人所開發的瀏覽程式時,根本無從下手。這兩年有需要修改的部份,仍然要請VB超人撥冗修改。就算鳥毅有心想要花時間研究,但來自使用者的壓力與其他業務根本不允許花幾天去看別人的程式。

此時或許會有朋友說:重構就好了嘛!在VB6沒有重構工具的情況下,要不影響原程式重構實在很困難;就算能重構,光修改變數和物件,就不知道要花幾天時間。

侯捷在重構的譯序裏提到:
我比較擔心,閱歷不足的程序員在讀過本書後可能發酵出「先動手再說,死活可重構」的心態,輕忽了事前優秀設計的重要性。任何技術上的說法都必須有基本假設;雖然重構(或更向說 XP,eXtreme Programming)的精神的確是「不妨先動手」,但若草率行事,代價還是很高的。重型開發和輕型開發各有所長,各有應用,世間並無萬應靈藥,任何東西都不能極端。過猶不及,皆不可取!
事實就是如此,重構不是萬靈丹,好的開發方法與演算法遠勝過程式技巧。事前的需求分析與架構的設計,在一開始就決定軟體的未來。(這幾年已漸漸沒在寫code,所以看到 重構-向範式前進 雖然很想買,但看了也用不到,還是作罷。)

XP和CMMI不同,並不是空泛的教戰守則,而是大師的經驗法則。勿以善小而不為,用在XP上亦然呀!拿一間已被收購的入口網站舉例:這間公司在香蕉國拿下超高流量,但是裏頭RD各寫各的程式,雖然每個人的code都有交出來,程式技術也夠,但是卻因為沒有好的code conventions,舊服務大改版時幾乎都得重寫,服務移交給新人維護時也有許多困難,常常得找原開發者。我想這在許多中小企業也是一樣吧?只是MIS流動率較低,通常還找得到原開發者。

3 則留言:

An Embedded System Engineer 提到...

這是陳年的痛處吧
久而久之,總是有個獨霸系統的 super programmer 存在

時常看到砍掉重練的事發生
然後又樹立另一個 super man

有解嗎?
無解嗎?

鳥毅 提到...

An Embedded System Engineer,當然有解囉!

只要全面使用Pair Programming,每個programmer都是super programmer ^_^

Kun-Yi 提到...

中小型的公司能找到一個maintain program 的人就不錯了
Pair Programming 好像滿難的
上面的大老闆只會看到原本只需要一個人力 瞬間變成2個人力成本大增加, 直接來砍劈吧