讀了套用Pattern的程式碼，會不會見樹不見林？

June 11 08:22~09:09

 

先打個廣告，6月21、22、28日 (六、日、六)舉辦的「Design Patterns這樣學就會了：入門實作班 」已經確定開課，早鳥優惠到6月16日（禮拜一），對設計模式以及Alexander的模式與設計理論有興趣的鄉民們歡迎參加。

***

一位「Design Patterns這樣學就會了：入門實作班 」的學員在課程結束後問Teddy…

學員：如果新人讀了套用Design Patterns的程式碼，會不會只看見個別的pattern而不知道整個系統的運作，有一種見樹不見林的困擾？

Teddy：的確是有可能，但廣義的來講，把程序導向程式改成物件導向程式，就可能會發生這樣的問題。因為原本在程序導向程式中，那種一步、一步由單一物件或函數直接處理問題的作法，在物件導向設計中變成了一組物件彼此的互動，從這個觀點來看，程式的確有可能變得比較不易理解。

學員：那怎麼辦？

Teddy：我覺得這個問題其實程序導向程式也會發生，只要是系統稍大之後，閱讀程式碼的新人就可能會產生樹不見林的困擾（只看到小部份的設計而不知整體架構）。

Teddy：這個問題有好幾種手段可以解決，傳統的軟體工程方法，要求建立需求與實作設計、程式碼之間的「追溯性」，開發人員可以先從需求面著手，了解「樹林」之後，在往下去看這片樹林裡面的每一棵樹。但是，這種方法要求開發團隊要隨時維持需求與實作之間的一致性，需求改變同時要更新需求文件、程式碼、以及兩者之間的「追朔性」關係。這是一種非常繁瑣的工作，實務上在台灣很少有開發團隊可以做到這種要求。

學員：還有其他方法嗎？

Teddy：還有兩種常見的方式可以來避免見樹不見林的困擾，首先，你可以幫系統建立起軟體架構區塊圖（architecture block diagram），讓新人先了解軟體架構之後，再去看程式碼。就好像一個人來到陌生城市旅行，總是要先看一下地圖在去探索，這樣比較不會迷路。如果在探索過程中迷路，就把地圖再拿出來看，確定自己所在位置。

學員：對了，我讀過你的《笑談軟體工程：例外處理設計的逆襲》，你在書中說過，軟體架構提供一個global context（全域情境），可以協助例外處理設計。

Teddy：如果我們把系統原始碼當作一個城市，軟體架構就是地圖，不但可以做為例外處理設計的參考，更可以協助我們了解一個系統。

***

學員：你剛剛說有兩種方法，另外一種是什麼？

Teddy：寫測試，寫各種不同層次的測試。

學員：不同層次的測試？

Teddy：單元測試、整合測試、驗收測試等。當你要了解一個函數，就去看單元測試。你要了解一組物件彼此如何互動，就去看整合測試。你要知道系統功能，就去看驗收測試。

學員：可是我們沒有寫任何自動化測試耶…

Teddy：這就是為什麼這雖然是一門Design Patterns的課，但我在上課中要一直強調測試的重要性。測試除了可以幫你找出程式中的問題、縮短除錯時間、增加團隊成員與客戶對系統的信心、協助開發出clean code，還可以作為理解系統的一種手段。

學員：我了解了，謝謝。

***

友藏內心獨白：無論是否套用設計模式，以上兩個方法都可協助開發人員了解系統。