2001/01/22

漸進式創新法
分類:創新


不斷創新,不斷思索變革之道,也就是要不斷地追求改善。

我想各位聽到「創新」,一定馬上想到龐大的研發費用、一批聰明絕頂的研發人員,NO!錯啦!「創新」並不是來自靈感、來自某幾個發明家。管理大師彼得杜拉克就曾說過:「創新並非來自天才,與靈感也不相干,而是來自辛勤、有系統的工作。」事實上,根據調查,創新的來源也是「漸進多於突破」、「學習多於發明」──取自某演講稿。

一般的程式設計師總會陷入一個迷思,就是只要做好維護的責任,或者是要重視新功能的開發動作,有時因為痛恨舊的架構,所以經常革命性的打掉舊有的程式碼重新再寫過一次,而有人就會有鴕鳥的心態,只是再舊的程式碼裡面加一大堆的特殊處理,來因應不斷出現的狀況,這兩種現象都是太過的做法,雖然都可以解決,但是都會出現很大的陣痛,革命型的做法容易導致客戶有一段的適應期 (debug)時期,時間一拖長,客戶就走掉了,鴕鳥型的做法容易導致一個系統的架構混亂,愈來愈不容易更動。

所以一個良好的系統演化,必須要靠的就是程式設計人員,對於一個系統的觀念是否能往正確的方向走,也是程式設計師的責任,不諱言的,良好的執行者所受到的鼓勵並不是短期間可以看的到的,系統創新的評比也很難在考績上面表現得出來。以下提供幾個漸進式的創新方法......

模組化是一個非常好的方法,只要把模組化當成你的工具,慢慢地將不適用的模組抽換掉,你就可以把系統架構簡單化,未來要加新功能的時候不用在東一個、西一行的加入程式碼來處理例外狀況了。

做紀錄檔統計效能,使用者如何操作系統最清楚的並不是程式設計師,也不是系統分析師,是程式系統的本身,您只要在重要的程式碼做一些紀錄,當然不能影響系統的效能,然後適當的分析這些紀錄,可以很容易的知道系統的瓶頸在哪裡,未來可以用什麼平台、什麼程式語言來開發比較好維護。

絕對不要特殊處理,特殊處理的程式碼就好像是滾雪球一樣,如果是一個大的斜坡,你就會越滾越大,講難聽一點,就好像是說謊一樣,你經常要說另一個謊,來掩飾前面的錯誤,如果架構不對,就要找時間勇於改善系統的架構,花了一個星期來改架構,總比未來花兩個星期來找出 Bug,然後可能賠上幾個系統不穩定的評價好的多吧!

經常在別人的工作報告上看到,了解XX系統的架構、修正XX系統的Bug,其實,這些字句都不應該出現的,除了目標不明確之外,要彌補之前的錯誤,就安排了一大堆的進度,真的非常浪費資源的。

延伸閱讀:【流程】軟體開發過程階段性目標與相容性的做法

總共有1個迴響

  1. Kenming Wang 4/22/2005 9:28 下午

    將模組(Module)二字改成 "元件(Component)。以元件為單位可能會比較適中。 :-)