簡單聊聊軟體設計的 SRP (Single Responsibility Principle) 原則

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

SRP, Single Responsibility Principle (單一責任原則)

這是上星期課堂中,當我解釋 Multi-tier MVC 分層結構時,聽到學員告訴我的。

哈,這是我第二次遇到學員有告訴我這個術語,看來都蠻熟悉 Martin 在 "Agile Software Development, Principles, Patterns, and Practices" 一書內所提到的幾個軟體設計原則。

不過當我問他們工作上是否至少有把 UI 與 Logic/Data Acess 層分離? 沒有!還是全都攪在一起,沒有人講究上述分層的 "基本責任分派"。

沒有「知行合一」,確實實踐並從實務中體會與調整作法,那麼,學會 "背" 這些術語是沒啥用處的!

其實也只有一個字需要真正了解:責任 (responsibility)。

o Web UI (view & ui controller) / Standalone UI:Presentation (只負責傳送與回傳已運算資訊)。

o Domain Controller:負責控制流程 (control flow)。

o DAO (data access object)/ Adapter:負責連結資料庫/外部系統。

o Entity (或稱 business) Object:負責處理邏輯運算。

確實理解 "responsibility" 這個術語可不是用背的,而是身體力行,從過程當中去體會該術語的「真諦」。

從原點出發,一個詞彙可通一堆觀念。如當確實做好單一類別的責任分派時,所得到的效果就是「高內聚力 (high cohesion)」—責任明確。

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

** 本文同步發表於 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);兩者可以形成很好的互補,並非是拿來比較、相互衝突的。

新竹某科技大廠的 Kick-off 系統開發顧問輔導

昨日一整天在新竹某科技大廠展開為期三個月的系統開發暨人員技能培訓的顧問輔導。團隊主要輔導人員,包括 Ringle, Arthur, Steve 與我都一同參與這第一次的 Kick-off 輔導 Meeting;爾後是每一星期至少一次 On-Site 對該資訊單位,約 20多位的開發人員從某一 Web Portal 系統開發實務過程中,協助關於系統架構/需求分析/結構設計/程式實作的技能/技術輔導。

輔導對象的資訊開發人員大都只有 VB6 的程式撰寫經驗,而新系統的開發卻是 Web Portal by ASP.NET MVC & C#.NET 物件化的語言。

有趣的是對方負責總體專案管控的 Manager 以為今天我們過去只是先了解下他們系統大致的功能需求而已;殊不知,我跟他們說今天就要產出可執行的程式碼!他們都露出驚異不容易置信的表情。

所以早上先從大業務流程的分析,產出 Eriksson-Penker 的火箭圖;再針對其一的作業流程產出以人本角度的活動圖。然後就是從其中規劃使用案例模型,分析主要的使用案例以及使用系統的參與者,還有與外部系統整合的參與者。

閱讀全文 »

關於 PTT Soft_Job 對於 OOP 的一些回應

沒想到 PTT 的 Soft_Job 看版有人在聊 OOP 的觀念,忍不住作了一些回應。

  1. 早期把物件化的分析/設計思維歸為 OOA/OOD (Object-Oriented Analysis/Design);實現物件化思維的程式語言則稱之為 OOP (OO Programming)。
  2. 實現 OO 思維主要有兩個機制:介面 (interface)、多型 (polymorphism)。包括 .NET/Java 等主流語言,早已支持 OOP,甚至連 php/python 等原來屬於 script-based 的程式語言,也朝向 OO 化的實現機制。
  3. 從 OOP 的角度來看到物件化的設計思維是不妥的;原因在於絕大數開發人員並不知道 Why OO Thinking!其實採用 OO 設計化思維是必然會增加開發成本的。因為它並非為了解決某一局部的邏輯性問題,而是考量全局,從系統整體來看待「變動 (Change)」的議題,進而提出如何擁抱改變 (embrace changing)的解決方案。
  4. 再則從實作上,OO 化的特徵是分散式的 (因為基於類別 (class)的責任分派 (responsibility assign)原則)。所以為了實現 OOP 的分散式架構,程式碼必然大量分散於各類別內,如此會造成實作與偵錯的難度;因而一個必要的配套措施:TDD (Test Driven Development),測試先行是一定要養成的好習慣。
  5. 越是大型變動頻繁、高度維護,或者期待包裝為產品,增加其再利用性價值的系統,採以 OO 的設計/實現 (當然,前提要有這樣實在技能的軟體架構師/Developer)才能感受到其好處:每一次只改變一點點;每一次的變動可以侷限在可控制的變動範圍內。
  6. OO 的特徵是將 程序/資料 封裝至某一類別內,其實在抽象層次,程序稱之為「行為 (behavior)」、資料稱之為「屬性 (attribute)」,兩者均為物件必然會有的特徵 (features),是非常自然不致分離的。但因現實仍沒有一種有效的機制能把物件的狀態 (state)儲存起來,所以實作技術上是把物件與資料分離,資料儲存於資料庫系統內、待執行期間 (run-time)才透過如 OR Mapping (如 .NET ER Framework、Java Hibernate 等),將物件與資料合而為一。
  7. 實業界很有趣的一個現象:重視 MIS (Management Infomation System)系統的公司,幾採以資料導向的開發模式;重視 Web 框架如網路行銷公司,大都採以程序導向的開發模式。至於所謂的 OO 化,實現的程度其實還蠻微小的。
  8. 順待提下重構 (refactor)的觀念:重構是屬於事後 (Coding 後)的設計,一般與事前 (Coding 前,如典型的 SA/SD)設計可能存在著 3:7 或 4:6 (事前:事後)的比重。而且往往寫完程式才是另一段故事的開始:持續重構 (continous refactoring)。
  9. 重構的要件:不會影響到已經上線系統的所有功能。 衡量重構的指標:每一個 method 不會超過 10 行、最長不得超過 20 行。
  10. 如今重視 Web 相關技術、快速實現商業創意的年代,其實已少人有人談及 OO 更遑論具體實踐了。西元2000年以前,包括 UML 三大師 (Booch、Rumbaugh、Jacobson)、Martin Fowler (重構一書即為他的著作)、Kent Beck (XP/Agile 的始祖)、Bob (Clean Code 作者)均為支持物件思維的軟體大家。國外除了這些大師外,實現 OO 的專家其實也不多,一般是會落在如開發底層框架 (如 .NET Framework)的關鍵架構師。
  11. 閱讀全文 »

[活動紀實] EA UML工具研討會@加爾第咖啡

** 所有相關活動的完整照片,可至-「2012_1215_EA_UM L_新功能應用研討會」Flickr 相片集瀏覽。 **

** 本次簡報下載:2012_1215_EA新功能研討_簡報與Model檔.rar **

EA研討會@加爾第咖啡

HSDc. 舉辦之「EA UML 開發工具新功能分享與應用 (12/15)」於上週六圓滿落幕,與會學員雖然只有10多位 (許多已報名學員臨時缺席,因有限制名額,望請爾後無法參與者請取消報名,保留給他人聽講權利。),但聽得開心吃得也相當滿足。

因定位是屬於小型的應用分享研討會,所以並沒有租用大型的會議室,而是就近在「吳興街」頗富好評的「加爾第咖啡」舉辦,她們家有可容納約 30 人的地下室,可供會議研討會或團體聚會等,約一個月前左右預約即可。而每個人最低消費為 NT$150 (這也是本次研討會報名費訂於此的原因,還附贈了一片歷年來的簡報與錄影教學等資料DVD光碟。)
加爾第咖啡

閱讀全文 »

寫一本書所構思的大綱-利用心智圖

上上個月底,與「悅知出版社」編輯約談喝咖啡,洽談寫書的相關事宜。個人想寫一本比較從架構思維的觀點來規劃與設計 雲端/Android 平台內容的書籍,並藉由一個案例研討 (case study),採用 目標導向/步驟實作 的方式,把整個開發過程,利用 UML/Java 呈現出相關的設計產出與程式碼。

待上個月底從「深圳」教課回來後,花了兩天的時間構思大綱,並先利用心智圖 (mindmap)快速整理成草稿,然後再轉成條列式的大綱 (outline),並寫成 Word 提案 (proposal),電郵給該編輯請之出版社審核,待核可後即開始整理動筆。

對了,同時 Ringle 也有他第二本書的大綱提案,他的主題是以中階軟體開發人員所想要的-設計樣式 (design pattern),他準備以 ERP 為主要案例,書內有三五個主題,每一個主題所涵蓋會使用到的設計樣式結成一串,來說明是如何應用這些設計樣式並實作的。

我不像 Ringle 如此的有條理,他只花一天的時間就完成了大綱的構思。反之我是藉由心智圖,先沒有條理、採取直覺放射的方式,把想法諸多枝葉細節先一股腦塞到心智圖內,再來慢慢地整理,長出主要的枝幹 (也就是寫一本書的主軸大綱等)來。心智圖草稿 (draft)不講究顏色美觀與否,快速地勾勒出心中的那張圖比較重要,以後相關細節再來慢慢調整即可。

底下為該心智圖草稿的縮圖,點擊鏈結後可以下載原尺寸的圖檔供參考。

雲端/Android/JML 寫書大綱心智圖

軟體思維顧問

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

Personal