By 高煥堂 2011/09/04

內容

• 敏捷軟體開發的原則
• 敏捷架構設計(Agile Architecture Design)
• 中層設計與EIT軟體造形  

1. 敏捷軟體開發的原則

     敏捷(Agile)概念來自於軟體行業。由於軟體開發專案的成功率偏低，以北美地區為例，有30%的專案未完成就取消了，大多數的專案費用幾乎超過預估的兩倍，這些危機，主要是因為開發軟體費時費力，而且客戶需求複雜而持續演變，讓傳統固定流程的開發途徑面臨巨大的困難。
     因此，於2001年2月11-13日，在美國猶他州的Snowbird鎮有17位方法學專家聚會研議，共同發表所謂「敏捷宣言」(The Agile Manifesto)，宣言包含有4項基本原則，如下：

     其中，”over” 意味著傳統上太重視右邊，如今右邊仍然有其價值，只是在敏捷觀念中，特別關切左邊，來平衡過度依賴右邊的副作用。這四項宣言特別關注於人的角色；其中，前兩項宣言聚焦於：溝通合作(Communication & Collaboration)；而後兩項則聚焦於：檢驗反饋(Test & Feedback)。基於上述原則，衍生出敏捷開發過程的主要概念：

• 最簡方案(Simplest solutions)
• 迭代過程(Iterative process)
• 重構(Re-factoring)
• 持續整合(Continuous integration)

     雖然敏捷思維是源自軟體(程式碼)開發行業，在宣言裡特別強調”可用的軟體(程式碼)”；然而，上述的2個焦點：<溝通合作>和<檢驗反饋>；以及4個過程概念都適用於各行業的規劃、設計、開發與建置的團隊合作活動。如下圖所示：

圖-1  敏捷的基本迭代過程

     此圖表示出，依循敏捷過程，以測試驅動(TDD, Test-Driven Development)引匯出持續地反饋(Feedback)與迭代(Iteration)的軟體開發過程。基於願景而設計足夠好(Good Enough)的簡單方案，做為基礎，儘快將設計落實成為程式碼；然後以需求來進行檢測，將測試結果反饋回來，修正和重構設計和程式碼，持續迭代迴圈下去。於此，我來引用著名軟體架構師Fred George的話，他曾說：

       ”Kent Beck曾經說：<程式碼就是設計與殘酷現實(需求)的明暗交匯點>。他的意思是，我們能畫出許多美好的設計，但最好的設計僅僅是被翻譯為優雅程式碼的那些。一個無法將願景(即Vision)帶入程式碼的架構師將無法洞悉這個急速變化城市所呈現的面貌。”
“Code is when design meets the harsh reality of dawn.” He was saying that all designs look pretty when we draw them, but the best design translates into elegant code. The architect that doesn’t carry his vision into code will never gain the insights that our changing industry exhibits.

     透過TDD來驅動敏捷迭代過程，迅速將願景帶入程式碼裡，透過及時反饋促進人員的大量溝通，迅速重構設計(含調整願景)和程式碼，以便敏捷地響應外在環境和需求的瞬息變化。

2. 敏捷架構設計(Agile Architecture Design)

      上一節所談的敏捷原則和過程，並沒有明顯地區分<架構設計階段>與<程式碼開發階段>；而是融合在一個迭代範圍裡。那麼，如果有必要將上述兩個階段切分開來時，變成兩個迭代範圍時，又該如何運作呢?
      首先我來談談如何將敏捷迭代&反饋機制應用於設計階段。架構設計階段與程式碼開發階段的主要區別是：相對上，架構設計階段創意空間較大，因而對願景(Vision)的依賴比依賴比較大；而程式碼開發階段則對需求(Requirements)的依賴的比較大。

兩階段敏捷迭代之間的銜接

      首先，回顧上圖-1裡的傳統敏捷開發過程。然後將其”設計”區分為兩部分：<架構設計>與<細部設計>；如下圖所示：

圖-2  將傳統的”設計”分為兩部分

      這兩個階段，幾乎都是先進行<架構設計階段>，然後才進行<細部設計階段>。這兩階段之間有些時間的落差。如下圖所示：

圖-3  兩階段之間的時間間隙

      由於兩者時間先後不一致，兩者之間有時間間隙，使得程式碼開發階段的敏捷迭代(Iteration)機制無法覆蓋到架構設計。於是，一個巨大的難題出現了：如何確保架構設計的<可實現性>呢? 於是，我獨創了一個新的層級：中層設計。這個<中層設計>是軟體介面定義層，用意在於使用軟體開發的TDD(Test-Driven Development)分法來檢驗架構設計裡最關鍵的<介面>(Interface)部分，為系統整合進行測試；提升架構的整體和諧，及其可落地性。
      在架構設計階段，依循敏捷途徑，以測試驅動(Test-Driven)引匯出持續地反饋(Feedback)與迭代(Iteration)的中層設計(即軟體介面開發)過程。如下圖-4所示。

圖-4  <架構設計階段>的敏捷迭代過程

     經由敏捷TDD機制來執行介面軟體，實際檢測資訊交換的所需的軟硬整合裝置，以及相關通訊機制。產出計算機可執行的軟體介面控制程式碼，就是中層設計的作品了。
     到了將來軟體開發階段，上述中程設計所產出的軟體介面程式碼，就交付給軟體開發團隊，結合其細節設計，一起參與開發階段的敏捷迭代過程。中層設計是在<架構設計階段>所完成的，屬於<架構設計階段>的工作範圍。到了<程式碼開發階段>，我們將會拿中層設計所產出的軟體程式碼，來做為軟體開發階段的基礎；也就是開發階段進行敏捷迭代過程的單純起點，在敏捷開發概念裡，稱為：簡單方案(Simple Solution)；如下圖：

圖-5  <程式碼開發階段>的敏捷迭代過程

     由於架構設計的決策必須具備未來性，此時敏捷思維裡的迭代、反饋與溝通(合作)，是架構設計過程中必須具備的<敏捷性>。敏捷架構設計與敏捷開發，其實是可以分階段，並且能透過中層設計來做無縫隙的銜接。於此，我套用前面(第1節裡)Fred George的說法，成為：

“架構是遠景與殘酷現實(需求)的黎明交匯。我們能想象出許多美好的願景，但最好的願景僅僅是被翻譯為優雅架構設計的那些。一個無法將願景帶入架構的頂層設計師將無法洞悉這個急速變化城市所呈現的面貌。”

     從上圖-4和圖-5可以看到，這兩個階段的銜接是很和諧流暢的。敏捷思維的核心是：以跌代(Iterative)過程帶動反饋；以反饋促進溝通(與合作)。這項思維非常適合於架構設計，於是兩個階段的迭代思維是一致的，也就很容易(透過中層設計)將傳統軟體開發的敏捷思維和原則擴大到大型系統的架構設計。

3. 中層設計與EIT造形

     敏捷開發過程的主要概念是：1) 最簡方案(Simplest solutions)；2)迭代過程(Iterative process)；3)重構(Re-factoring)；4)持續整合(Continuous integration)
     其中的第一項：最簡方案，就是從一個足夠好的簡單起點出發，進快啟動迭代&反饋過程。為了滿足實踐階段的迭代過程的要求，我獨創了一個超級簡單的軟體造形，稱為：EIT軟體造形。一方面，它能完全表達中層設計的軟體介面結構，能立即落實為程式碼，讓頂層設計階段能儘快展開敏捷迭代過程，並能產出計算機可執行的介面定義程式碼。另一方面，此EIT造形既足夠表達頂層的互聯互通的介面定義，又非常簡單。剛好滿足敏捷的<足夠好又簡單>的起點要求。此EIT造形如下：

圖-6 高煥堂設計的EIT軟體造形

     一旦中層設計與EIT造形結合之後，其整體架構就如下圖所示：

圖-7 高煥堂設計的><中層設計+EIT造形>

     造形是軟體<集裝箱>，程式碼開發人員可以將軟體程式碼直接新增到中層設計的EIT造形裡。而且能設計EIT造形幕後的形形色色軟體程式碼，來處理細節計算。所以，中層設計裡的EIT造形的創意組合結構，能順利成為實踐層的主架構(Architecture)。基於這個主架構，實踐層的架構師可以增添較為細節的設計規範，包括軟體、硬體平臺的選擇、資料庫設計、程式碼測試方案、效能優化設計等實踐層級的細節考慮；成為軟硬整合的系統架構。
     軟體造形所創造的簡潔性，就可針對各系統之間互聯互通的介面部分，以明確的軟體程式碼來定義之；以唐代”詩同形”途徑來提升架構設計(和中層設計)的<明確性>。才能有效檢驗架構設計的<可實現性>。愈大規模的系統開發，其中層設計就愈重要；而造形則扮演核心角色。因為它為上、中、下層人員開創設計概念的一致性(Conceptual integrity)，讓他們獲得一致的共識(Shared understanding)。◆