邁向架構師的暖身運動 (10) : 動乎?靜乎?

一般來說,設計與規劃一個軟體系統,不外乎是符合需求,具有前瞻性,創新力,或是試水溫等等,不管是哪一種,只要是一個有經驗 (或是現在就在做) 的系統設計師 (系統分析師亦然) 都會想要把軟體系統設計得具有十足的彈性,並且具有無限的擴充性,

這個題目是看了某個討論和某個噗而動念的。

一般來說,設計與規劃一個軟體系統,不外乎是符合需求,具有前瞻性,創新力,或是試水溫等等,不管是哪一種,只要是一個有經驗 (或是現在就在做) 的系統設計師 (系統分析師亦然) 都會想要把軟體系統設計得具有十足的彈性,並且具有無限的擴充性,可以適用於各種想的到的環境,簡言之,就是將軟體系統設計為一個有機體。有機體可以自由的依環境的特性而變化,在完全不用修改 (或極少修改) 的情況下即可將系統建置於任何環境中。這當然是許多軟體設計師的最高境界,但,說真的,有機體的軟體設計難度非常高,除了要有異於常人的前瞻思考外,還要有一手很高超的技術 (或是一個擁有很高超的技術的團隊) 來實現,否則想把軟體設計成有機體,幾乎是 MISSION IMPOSSIBLE。

具有機體能力的軟體,其中一項特異功能就是能適應各種環境,而想要讓程式碼能夠適應,那麼絕對不可以是靜態 (static) 的設計,而必須是全動態 (fully dynamic),全動態的架構可以因應不同的環境快速的變更,以適配當下的環境與需求,它相對的一個詞是全靜態 (fully static),全靜態的架構只能符合特定的情境或環境,雖然沒有全動態的彈性,但卻有無比的速度,理由很簡單,因為所有的流程都是固定的,不需要對環境做出妥協,也不需要因應環境自動調整,所以省下那些時間的結果,就是得到比全動態更優異的速度和效率。雖然靜態的好處比動態好,然而過於靜態對系統的延展性和擴充性有很大的限制,更進一步的會影響到使用年限,因為商業或系統環境是會改變的,Process 1.0 可能幾天後要改成 Process 1.1,出貨流程可能會因為倉管的要求而加入檢查機制,銷售獎金可能會因為公司改變計算方式而有所不同等等,如果軟體是靜態設計法的話,可能一天到晚都要重新 build-deploy,不斷的輪迴。

所以系統到底是要設計到多動態 (or 多靜態) 呢?

對於一個商業應用程式 (Business Application) 來說,除了基本的需求外,也需要針對可能有變化的規則 (business rules) 進行特別設計,而這個部份一定要使用動態的作法,可用的設計架構像是 Strategy Pattern 或 Abstract Factory Pattern 等,配合 Reflection 來設計,以保持該有的動態能力,也可以增加系統的可維護性。而針對一些不太會變化的部份 (如系統管理功能或是系統基礎核心) 則可以用靜態的作法,以保持該有的執行效能。

對於一個 Framework 或是核心應用程式架構 (Application Architecture) 來說,動態能力則會是重點,因為服務的對象是應用程式開發人員,所以會用到許多的動態技術,Reflection 只是小菜而已,像 attribute, Control Design, Visualization, Rendering 等等都有可能會涉獵到,以 Web Application 來說,HTML, JavaScript 真的只是一小部份而已,具有動態能力的 Framework 會隨著開發人員所設定的環境而所有變化,但也不是 100% 都動態,像是連接 Framework 和 Application 的介面 (interfaces, contracts) 就不能隨便變動,否則會有版本相容性的問題,同時各式輔助函式或工具函式,也可以以靜態方式設計,來加速處理以及提高重覆使用性 (Reusability)。

動乎?靜乎?適當的設計,讓系統動靜皆宜,有何不可? :)