「資料導向」vs. 「服務導向」的開發模式

** 本文同步發表於 FB 社團-軟體設計鮮思維 **

傳統且比較直觀的開發方式係採以表單 (form)畫面為單位、然後連結資料庫直接存取資料,這是屬於相當典型的 Client/Server 2-tier 開發模式。

即使轉移到 Web 採所謂廠商提供的 Web MVC 框架 (如 Java Spring MVC),但那也只是 Web 端的一種技術解決方案 (解決 Web Page 狀態控管問題);然後再使用廠商提供如 Java Spring O-R Mapping 機制 (如使用 Hibernate Framework)連結資料庫,這仍是傳統的 Client/Server,重視以資料為導向 (data-oriented)的開發方式。

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

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

採以「使用案例 (use case)」搭配 Enterprise MVC,則是屬於「服務導向 (service-oriented)」的開發模式。

閱讀全文 »

簡單描述 SCRUM ~

** 本文同步發表於 FB 社團-軟體設計鮮思維 **

SCRUM,這幾年最夯的開發方法論。

它比較像是團隊版的 GTD (Getting Things Done)時間/工作管理。因為是 Team Work 性質,所以還需要再佐以 Review Meeting (Daily/Weekly) 來檢視與回顧團隊成員的產出。

主要有兩個關鍵字須充分理解:

  • Backlog (訂貨):大訂貨 (product backlog)是由多個小訂貨 (sprint backlog)所組成;每一個小訂貨被視為是可被計量的工作事項 (work item)。
  • Sprint (衝刺):等同於現今所有實務開發均認同的 Iteration (循環,或稱迭代)。這是最重要的成敗關鍵,也是實踐過程中最難以克服的。 (一個 iteration 要涵蓋整個開發步驟,但又要能適時地量化一個工作目標,這不容易。)

特別再強調!SCRUM 只是一種做事的方法,它可能可以調和專案的 時程/規模/成本 三個因子,讓專案目標比較有機會在特定的期限內達成。

但是,SCRUM 與軟體品質完全是兩回事。許多開發人員以為導入 SCRUM/相關工具就能把軟體品質做好,那是不可能的。

軟體品質仍取決於對軟體設計的技能/技術的掌握程度。諸如對需求的分析/收納整理;系統結構的應變設計;實作技術的應用 ...等。

軟體開發工具越是易用強大所以不需要作設計?

** 本文同步發表於 FB 社團-軟體設計鮮思維 **

昨日與一位業界的前輩喝咖啡聊聊 (兼談合作事宜),他是國內頗負盛名的 CMMI 輔導認證的顧問。

雖是相當資深且擔任多家知名大企業的顧問,但仍孜孜不倦,時程總是排滿,利用空檔時間至許多技術課程單位當學生,藉此了解下業界採用所謂的方法論/新技術...等。

他分享了兩件軼事:

  • 他至台大上 C#.NET 語言入門課程,有約40來位的學員上課。
    講師竟然跟他們說,現在系統開發根本不需要設計,只要會操作工具、拉一拉畫面,簡單的下幾個指令,就可以很快速的產出應用程式。
  • 他上某單位現在最夯的 SCRUM 開發流程課程,講師拿它與其它方法論比較,甚至還嚴重的批判,而其中更是包括了 CMMI (顯然誤解,它並非是流程方法論)。

    這位前輩很感慨甚至有些不悅,尤其是批判到他的專業領域-CMMI,明明就只是一種制定達成目標的框架而已,怎麼會是拿來與 SCRUM/Agile 等相提並論呢?

他認為講師應該是擺在以該課程的主題為中心來傳授相關知識與技能的,但怎麼能對自身並不了解的領域妄下斷論/批判,進而傳達非常不正確的觀念,這豈不是誤人子弟呢?!

哈,其實軟體業沒啥新鮮事,這些見聞也都早已習以為常了。尤其是隨著系統開發廠商提供的工具/機制越完善,雖然可以大幅減低開發的時間,但卻也造就了軟體人員的墮落,過度地依賴這些工具的使用,卻少有思考軟性較具本質性「虛」的那一面向

我與那位前輩稍微解釋下,針對第一點,講師只要稍微修正下講法即可。不是不做設計,而應該是說抱著「簡單設計 (simple design)」的態度 ,事後再佐以「重構 (refactoring)」來逐漸修正調整,快速的 I&I (iterative & incremental)以構成設計/實作一體的開發循環。

設計是必然會做的,但該講師顯然誤解所謂的「設計」是那種以往 (其實現在也很多單位是這樣做)要做仔細規劃、產出一堆文件卻不適用實作的 Waterfall 方式。

至於 CMMI 與 SCRUM/Agile/RUP 等方法論之間的關係,我在9年前就曾發表過「利用 UML 類別圖表達 CMMI Content 與範例說明」。

其實簡單的說,因為 CMMI 只是制定各等級所謂成熟度的目標框架,但它並沒有提供要如何 (How-to)達成 (achieve)的作法;如何達成正是這些方法論可以提供的,所以其實把 CMMI 視為 Interface,上述方法論視為是實現 (realize)該 Interface 的具體性類別 (concrete class);兩者可以形成很好的互補,並非是拿來比較、相互衝突的。

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal