漸進式創新法分類：創新

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

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

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

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

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

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

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

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

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

撰寫規格文件的重點分類：管理

一個好的系統除了要有良好的架構之外，他的價值有一大部分是不斷的維護系統而符合需求，貼進客戶的實際需要，這個中間修改的過程除了人的因素之外還有設備的更新，作業平台的轉變所造成的種種變因，所以留下規格文件供未來的人來參考改進非常的重要。

文件撰寫的重點並不是要寫的通順或是像寫小說文章一樣來湊字數，所有的開發文件林林總總，我們這一次討論的重點放在軟體系統規格的部分，由於程式設計師總是覺得寫程式看程式碼就好了，但是如果過了一年之後，你回去看你的程式碼你還會有印象嗎？更何況是別人要看你的程式碼了，其實規格文件的重點只有幾項，就是系統平台、程式碼架構、傳輸協定、檔案(資料庫)架構、模組流程等五大項，有了這些文件，往後的人員只要花個幾分鐘看一下，就可以很容易的維護別人的程式及系統了。

系統平台：其實是最好描述的，只要說明作業系統是Windows95/98或者是Linux、AS/400等等，然後使用的開發工具是VB/ASP或者是Visual C++,BCB 等等，最好要把版本號碼或是一些比較特殊的程式庫也要列上去。

程式碼架構：這一項通常會被大部分的人所遺漏，很多人是靠開發工具所提供的整合環境來分類，固然是很好，但是每個人應用的專案檔案（*.DSW,*.DSP,*.IDE 等等）並不會相同，也就是說你好不容易整理好的專案檔，也寫了一大堆說明文件，但是只是給你自己用而已，這部分最好還是要寫辦法製成文件分享給所有的人。

傳輸協定：無論是區域網路、網際網路的協定，或是單機自己內部傳遞資料一定有傳輸的協定，最普通的當然是TCP/IP了，而現在WEB Server或是EMail Server 的普及很多系統都應用網路七層協定的更高層來傳遞資料，這些都應該說明清楚，如果系統出來問題才知道如何查詢，而Windows系統內的訊息傳輸，也算是傳輸協定的一種，而兩個模組之間的Function傳遞也是，如果是重要且獨立的元件模組，應該要特別的強調才是。

檔案(資料庫)架構：除了關聯式資料庫比較容易寫出規格之外我們經常應用到的設定檔(Config)，例如*.INI的檔案，還有為了系統效能或是儲存資料、交換資料所儲存的資料檔案，應該都要有格式的說明，以及生成時間版本號碼的資訊，有了這一個規格表，即時是程式碼不見了，我們都可以很容易的重寫出部分的模組，而不用經常得去猜去破解一些資料檔的格式。

模組流程：是最早最早結構化資料分析的時候必須具備的流程圖，但是在物件導向的程式開發，我們經常會把流程圖隨著物件化而簡化，但是也僅僅是改良罷了，他的精神就是輸入與輸出的前後順序一定要清楚的表達出來，雖然現在的程式系統應用了很多訊息是觸發的事件來處理或是多執行緒的程式處理，一個良好的流程圖也可以表現出一個系統的邏輯性，有助於找出系統需要改進的地方，與如何維護的方向。

做文件並不是主管或者是某一些人的責任，應該是所有的程式設計師應該培養要定期製作的能力，除了可以有良好的溝通方法之外，也可以重新檢視一下自己的系統架構，把自己的能力向上提昇。