前些時候，我們團隊所輔導 (並主導其中的核心開發)某家頗具知名規模的商務網站，該公司經營者總覺得他們原來的開發產出速度緩慢，希望能借重我們在實務開發上的經驗，而能改善開發製程，加速開發上的產出。

我發現到 (應該也可說是意料中事)，即使是擁有10幾個以上開發人員的大型網站系統開發，其所謂的系統分析/設計的開發模式仍是採以最典型的 Client/Server 方式。Client 端(也就是 Web 端)主要採以畫面為主的需求分析；Server 端則以資料庫的資料模型為設計核心。

簡單的說，這類開發模式是屬於「資料導向 (data-oritented)」，直覺且簡單，系統規模小且營運需求並不常變動，這樣是行得通的，而且在系統開發的初期會是相當快速的；但當營運規模大得經常會要求系統快速配合商務運作，「資料導向」的開發模式卻往往耗在所謂的「共用性整合」議題上太多等待時間了，那種有著「剪不斷、理還亂」的感覺，不僅讓人苦惱，也是引起紛爭的主要來源。

其實原因也很單純，「資料導向」實際上早已悖離了軟體開發的第一個最基本原則：「封裝 (encapsulation)」。過早揭露資料與邏輯的細節，而使得系統的複雜度提升。

所以，該如何改善開發製程呢？當然就要懂得如何遵守「封裝」的設計原則，而採以 MVC (Model-View-Control)的架構則會是遵循封裝原則的第一個必要手段。

不過要釐清這裡所謂的「MVC」，可不是 Java Struts 或 ASP.NET 的 MVC 框架；系統廠商所提出的 MVC 框架，那是針對 Web 瀏覽器與伺服端如何控管 WebPage 狀態，是關於如何於 Stateless (無狀態)的 UI 設計議題所提出的解決方案 (solution domain)。

而關於企業層級 (enterprise)系統的 MVC 架構，則是回歸到問題領域 (problem domain)上，如何在呈現 (presentation)與業務邏輯 (business logic)兩個層級間，能有效隔離兩者的耦合性 (coupling)。

基於上述的開發原則，我們對開發流程的調整，其實就是在 client (Web UI)與 Server (Model)之間，規劃了控制層 (control layer)，藉以隔離中介 Client/Server 的直接耦合；Web UI 團隊與 Model 團隊係以平行分工開發 (parallel development)，各自依據其職掌－Web UI 專注畫面呈現與動態技術的實作；Model 專注於系統功能的實現 (realization)。兩者均只與控制層所設計的規格 (也可稱之為功能介面)溝通，所以誰不需等待另一方的產出，如此也就不用初期就耗在所謂共用性議題的等待上。

再者依照敏捷 (agile)的開發精神，整個開發產出係採以 I&I 漸增與漸進 (Iterative & Increment)，期待作持續性的整合 (continuous integration，以版本控制系統如 Git 作為整合的儲庫)。最好是每日就作整合，最遲不要超過一個星期。

關於敏捷式的平行開發流程 (agile parallel development process)，我們利用 Eriksson-Penker Business Extensions 語法 (俗稱火箭圖)所規劃的開發流程總覽 (overview)如下圖1。然後關於 Web UI、Control、Business Model 這三個層塊，再各自以 UML 活動圖 (activity diagram)來表述它們細部的開發活動，參考下圖 2~3。

（點擊圖片鏈接看原圖）圖1、敏捷式平行開發流程模型-Overview

閱讀全文 »