重構不是萬靈丹

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

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

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

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

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

侯捷在重構的譯序裏提到：

我比較擔心，閱歷不足的程序員在讀過本書後可能發酵出「先動手再說，死活可重構」的心態，輕忽了事前優秀設計的重要性。任何技術上的說法都必須有基本假設；雖然重構（或更向說 XP，eXtreme Programming）的精神的確是「不妨先動手」，但若草率行事，代價還是很高的。重型開發和輕型開發各有所長，各有應用，世間並無萬應靈藥，任何東西都不能極端。過猶不及，皆不可取！

事實就是如此，重構不是萬靈丹，好的開發方法與演算法遠勝過程式技巧。事前的需求分析與架構的設計，在一開始就決定軟體的未來。（這幾年已漸漸沒在寫code，所以看到重構-向範式前進雖然很想買，但看了也用不到，還是作罷。）

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