淺論架構的 POC (Proof of Concepts)

POC, Proof of Concepts, 從字面的意義來解釋的話,即為 “概念性的驗證”。

既然是需要驗證(Proof),所以 POC 是一種 “解決方案(Solution)”,是針對 “概念” 所提出的解決方案,而架構的 POC,目的即在於擷取出最精要、核心的解決方案(Solution),以作為解釋架構的概念依據。

我與 Ringle 聊到 POC,他原來對 POC 的認知是對客戶所提出的一種解決方案,所以主要滿足對象是 “客戶”。不過,對於架構的 POC,我不太認同對象是客戶,我會以為,會希望能透過某種概念性的解決方案,而對架構有整體、全貌性的認知者,那才會是架構 POC 的對象。

所以,誰負責撰寫架構 POC? 我認為是 “架構師(Architect)”,誰想瞭解及驗證架構 POC?我以為是開發團隊所有成員與利益關係人(Stakeholder)。

架構 POC 的對象釐清後,再來是瞭解其呈現的具體樣貌是什麼樣子呢?底下是架構 POC 具化的幾個可能樣貌。

  • 解決方案所需運用的相關技術(Framework, Pattern …)。
  • 利用 UML 語法建構概念模型草圖(Sketch),以表達某一解決方案。
  • 利用模擬(Simulation)的方式提出解決方案。
  • 可以被執行的原型 (Prototype)。

我個人傾向利用可以執行的原型(Prototype)來作為架構 POC 的具體樣貌,因為:

  • 架構師以 “原型” 做為與開發團隊與利益關係人的溝通、達成共識的橋樑,然後才著手執行。透過原型,大家比較容易對概念(Concept)產生共鳴,並致力改變尚未成形的東西。
  • 原型協助架構(Architecture)的建立,讓大家能容易看到整體、更具宏觀的角度來看待複雜系統。並因此而避免一頭就栽進種種的細節(Detail)。
  • 原型可把目標清晰地描繪出來,並且讓每個利益關係人(Stakeholder)都更容易提供意見,進行改革。

而且,架構原型可以:

  • 在架構落實以前,讓團隊成員能自由表達看法,並進行討論、提出建議。
  • 讓團隊成員隨時表達意見,有機會影響你正著手進行的方案。
  • 不斷加快前述兩個步驟(一般稱之為「快速建構原型」)。

對了,架構原型除了比較容易協助團隊成員一窺系統的整體全貌外,對系統內部的結構(Structure)分析與設計的呈現,也能有一番基本的認知。

所以,架構原型的內容,我會擺上表達整體系統的使用案例模型;實做兩、三個具代表性的使用案例,並畫上概念性的類別圖與循序圖;同時,我還會加上與 .NET or J2EE 等平台相依的細部類別與循序圖;實做面,確實可以產出可以執行的程式碼與測試碼;最後,我會利用簡單的 UI(User Interface) 作為執行畫面的呈現與說明。

原型,並非是 “粗糙”,或是 “應付性” 的,它是一個框,是可以被驗證的,但並非僅利用外表美美的圖形使用者介面來對系統作概念性的驗證。架構原型,反而不是重視圖形介面,它要強調的是一種對系統的整體觀與結構觀。至於圖形介面與企業流程的功能,反而不是那麼重視。精密與細節、正確性的工作,是對系統的整體有了正知與正覺,往正確的大方向走後,才確定要做的細節性工作,可以把它作對。人們,尤其是組織性的團隊,最常犯的錯誤是:「把不必要的事情作太好」。

文章導覽

   

共有 4 則迴響

  1. 通常那些不並要的事
    都會影響著你開發的速度
    不過有沒有必要,在我的認知,當我重複做2次以上後
    我就會開始嘗試修改更好的版本了

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *