I15 紙上談兵誰都會，真槍實彈的話呢？

“修改程式後應該通過所有相關的測試，才能保證程式是正確的。”我問過認識的所有軟體工程師，每個人都同意這個說法。再進一步問：“那麼修改程式後要如何取得正確範圍的相關測試呢？”，至今還沒有聽到有人提出理想的解答。(註)

這就是理論與實作的差距。很多聽起來很美好的理論，像是軟體外包會減少專案支出，軟體工廠的元件化能重覆使用程式可以降低成本，這些都因為沒有可以做到的方法而使得講求實際的專案根本無法導入。理論與實作在大家的口中都是無法串接在一起的平行線，軟體工程的理論變成討論時抬槓的內容而已。

在撰寫Blog後兩三個月內，心裡理論串接到實作的關節差不多都打通。在2007/11/12凌晨為了思考如何在專案裡套用軟工的作法，前前後後想過各個細節的作法、作用與影響；確認一切都能依序做出後，又再思量要如何向主管證明這樣做的好處以及施行的內容等等，到最後幾乎整晚都沒有睡好。之後的幾天，以心裡的想法與同事、主管們討論過實施的細節，慢慢地建立起每一個專案產出物件的關聯，同時套用設計工具並實作出一些簡單的開發工具來加速開發。

這真的是一條很長的路，在很多地方都需要認真思索該怎麼做、如何做才比較好，也難怪絕大多數程式設計者只想省事地做出符合功能的系統而不願花精力走這條路。但是，我以近兩個月內以這個模式迅速建構起兩個結構穩定系統的實作經驗告訴各位，邁向理想設計的路途雖然很難走，但是走過之後就絕對不會再用以前的方式做事……。

註：同事告知有xUnit Test可以作出涵蓋專案裡所有Use Case的測試，刻意在修改的程式裡傳回錯誤的值就可以立即發現哪些Use Case沒有通過而得知這段程式影響了哪些Use Case；不過要寫出好的xUnit Test內容投入的資源可能與開發這個專案相去不遠。而我自己的解法是先知道程式所在的method與使用它的所有Interface Method，然後去查詢所有使用到那些Interface Method的Sequence Diagram，所屬的Use Case Realization即是答案；當然，要記錄下所有的關聯也得花不少功夫。一切就看自己喜歡哪一種方式。