軟體開發方法論 | Kenmingの鮮思維

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

2016-03-08 20:41 | 閱覽人次：3,986 | 尚無迴響

傳統且比較直觀的開發方式係採以表單 (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 ～

2016-02-20 22:19 | 閱覽人次：3,047 | 尚無迴響

＊＊本文同步發表於 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/相關工具就能把軟體品質做好，那是不可能的。

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

論學習歷程的三階段－守破離《2》

2014-01-15 12:15 | 閱覽人次：6,823 | 尚無迴響

相當驚訝軟體業界的大師 Martin Fowler (UML Distilled, Refactoriing, NoSQL Distilled 等作者)，早已於 2006 年在他的 blog 內已發表了以「守、破、離」為題－ShuHaRi，說明在從事所謂的軟體技術與開發方法論上，所歷經的三個學習階段。

這裡特別把這一段的原文摘錄下來：

The idea is that a person passes through three stages of gaining knowledge:

Shu: In this beginning stage the student follows the teachings of one master precisely. He concentrates on how to do the task, without worrying too much about the underlying theory. If there are multiple variations on how to do the task, he concentrates on just the one way his master teaches him.

Ha: At this point the student begins to branch out. With the basic practices working he now starts to learn the underlying principles and theory behind the technique. He also starts learning from other masters and integrates that learning into his practice.

Ri: Now the student isn't learning from other people, but from his own practice. He creates his own approaches and adapts what he's learned to his own particular circumstances.

「守」的階段：Martin 認為學生主要遵循一位導師所教授並務求精確即可。這個階段不用太過探索理論基礎，而是在「如何做 (How to do)」上下功夫；也不要三心二意追求多種方法(論)，專注在導師所要求的主軸，把它做精就是了。
個人所認知的關鍵字為：學習、How-to、專注。
「破」的階段：有了基礎實務的經驗，學習者會開始來思索原來所學關於理論基礎與原則，並會逐漸整合其他大師的論述，帶入自己的實務工作上。
主要的關鍵字為：反思、整合、驗證。
「離」的階段：學習者已不全然由他人(導師)所學習而來，更多是從自身的實踐階段過程中，創造出自己所領悟的方法 (論)，並應用在現狀的工作環境中。
主要的關鍵字為：實踐、創造、驗證。

閱讀全文 »

[軟體開發] 敏捷式的平行開發流程模型

2013-11-11 22:13 | 閱覽人次：7,868 | 尚無迴響

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

我發現到 (應該也可說是意料中事)，即使是擁有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

閱讀全文 »

淺論中小型專案版控系統的基本分支(branch)規劃

2013-05-16 05:19 | 閱覽人次：7,051 | 尚無迴響

關於版控的分支與標籤的基本觀念，可參考原來寫的一篇：關於版本控管系統的分支(branch)與標籤(tag)的區別。

關於中小型專案規模的版控分支 (branch)規劃，個人以為應該至少有三條 (以 Git 為例)：master, develop , issue。

master (主幹)：作為對外版本的釋出 (release)。

develop (開發用分支)：作為內部開發的主要分支。其內的開發版本並不會對外釋出。

issue (支援性分支)：Bug/Hot-fix (臭蟲/重大更新), 新功能 (new feature) ...。一般紀錄於「Issue Tracking」系統內的問題/功能等待解決的 Issue，即會轉入該分支。

看圖說故事

（點擊圖片鏈接看原圖）圖、中小型專案規模的版控分支規劃

閱讀全文 »

關於版本控管系統的分支(branch)與標籤(tag)的區別

2013-05-13 16:43 | 閱覽人次：17,628 | 2 則迴響

版本控管系統：版本控管係為「建構管理 (configuration management)」的範疇。理論上，關於「分支 (branch)」與「標籤 (tag)」，從觀念上來看在各版控系統應是類似的，只是做法不同罷了。

Suversion vs. Git：雖然兩者常被拿來比較的是，subversion 是集中式的儲庫 (repository)，而 Git 則為分散式的。但若從專案管理者的角度來看，要管理的其實只有一個：位於伺服器上的儲庫。即使如 Git 可以有一堆分散式的儲庫，但管理者真正只有管理到例如儲存在 GitHub (or private Git server)上的儲庫。至於開發者在私人的儲庫內，要如何分支與標籤是自己的事，只要最終能提交給專案管理者做合併 (merge)即可。

（點擊圖片鏈接看原圖）圖、關於版本控管的分支與標籤說明範例

關於分支 (branch)：

原則上，任一版本管控系統只有一條主幹，例如 suversion 稱為 trunk，Git 稱為 master。
每一次對開發文件的提交 (commit)，可視為是一個節點 (node)。節點會持續隨開發時間推進，並期能達成所設定的里程碑 (milestone)。
如果把主幹的任一節點當成是可能對外發布的釋出 (release)，而這些釋出不希望與開發/維護期間的文件相互干擾，則可以另闢其它分支 (branch)，可與主幹並行開發並個別維護。主幹與分支(可能多個)盡量將耦合性 (coupling)降低，讓版本釋出與開發維護得以順暢並行。
分支後的開發/維護的節點，最終仍需將修改的文件回到主幹上，此時就必須做「合併 (merge)」的動作。

閱讀全文 »