實作 Enterprise MVC 巨觀結構的 POC-觀念篇

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

關於 POC (Proof of Concepts)的說明,可參考:「淺論架構的 POC (Proof of Concepts)」。

關於系統結構設計 (system structure design),個人把它分為兩個構面來看:巨觀與微觀 (Macro/Micro View)

巨觀結構設計是基於現實系統的分散議題-展示層 (如 Web UI)、永續儲存機制 (如 關聯資料庫),所提出核心業務邏輯應不相依於特定實體元件與實作連結技術的解決方案。這裡推出最實用具應變與可重構的實體分層框架-Enterprise MVC (Model-View-Control)模式 (並非是廠商針對 Web 端提出的 Web MVC 技術),讓系統主結構 (業務邏輯/資料存取)有效隔離展示層與永續儲存機制的直接耦合 (coupling)。

微觀結構設計則是傳統物件導向所談及從領域概念模型 (domain conceptual model),導出到軟體物件與資料模型 (class/data model)。這裡使用的分析設計技能包括了運用 Peter Coad 的「交易模式 (Transaction Pattern)」與 GoF 四人幫的「設計模式 (Design Patterns)」。有別於古典OO 一開始就要求較完整的設計 (太過理想化),現今系統開發則更為務實-運用重構 (re-factoring)的技巧,持續逐漸地重整系統,效果即是簡潔易維護的程式碼 (clean code)。而伴隨著重構的一項必要機制與紀律就必然要求一開始就要撰寫單元測試程式碼 (unit test code)。

上述兩個構面是互補的。軟體主結構一開始就不會實作於特定的UI/資料庫端,以最純淨的 POCO/POJO (plain-old CLR/Java Object)物件來實作,如此才有機會得以實施後續的重構,而重構則取決於某一功能的複雜度與價值來評估,進而創造出系統整體的再利用價值。

本文著重於巨觀結構分層界定與實踐,藉以驗證巨觀結構 POC 的可行性。觀念說明利用 UML 設計圖表現巨觀分層結構;實作則各以 C#.NET 與 Java/Spring 實現一個極小的案例來貫穿整個系統的分層結構元素。

C#.NET 採以 ASP.NET Web MVC 與 E-F (Entity Framework)實作;Java/Spring 則採以 Spring Web MVC 與 傳統 JDBC (也可改 Hibernate Framework)實作。兩者會再佐以 UML 循序圖 (sequence diagram),來輔助解讀案例執行時物件之間的互動合作關係。

巨觀分層結構基本責任界定

把主要分層結構當成元件 (component)看待,以界定各元件主要的責任 (responsibility)。

Enterprise MVC 主要元件責任界定

閱讀全文 »

軟體工程師與軟體設計師有什麼不同?

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

看到這篇文章:「What’s The Difference Between a Developer and an Engineer?」。這篇文章試圖比較 "軟體工程 (engineer)師" 與 "軟體開發 (developer)師" 的不同點與各自所需技能為何。

Software Developer 我覺得也可以稱為 Software Designer,同為設計原意。

若是我個人的解讀,軟體工程師比較著重在 "How-to" 的實作面。他會深入探究各類技術框架與工具的使用,舉凡 UI端 Javascript-based 框架、底層系統層級的技術框架、甚而包括了 3rd party 的 utiltiy 類型的 library 等;同時還有各種開發工具的精通。

軟體設計師,則會比較關注在 "What & Why" 的思考創意面。文內有提,設計師更會加強在心智上的修煉,包括自我學習、探討、觀察、閱讀等軟性功夫上 (不一定馬上就能應用到實務工作上)。

閱讀全文 »

Java Coding Style 內的 at-clauses 是什麼意思?

今天下午在龍潭某半軍事院所教授「軟體結構設計」系列課程,案例主要以 Java/Spring 來實作。

課後結束,該單位一位單純又可愛的年輕正妹送我出門 (視為廠商單位需內部人員陪同檢查證件),然後順便在會客室就近問我些問題 (好認真有心的女孩呢,假日還會窩在住宿處練習寫碼我提供的實作案例,值得肯定鼓勵)。

不過她問的問題反而不是我課堂教授的內容,是針對 Java Coding Style 某一部份的定義她不太了解。

啊,我極少重視這種所謂 "Coding Style" 議題,大概也只是縮行、空白行,盡量讓 method name、參數、回傳值等給予有意義的命名,整個敘述讀起來通順即可。

不過大型單位會要求這些也不是沒道理,總還是希望有所謂共同的寫碼基本規範 (不過反而沒要求 Method 陳述要控制在 30 行以內,這點期望能加進去)。

嗯,她問我的問題是 :
當全部的「at-clauses 」都出現時,其標準的使用順序為 @param 、 @return 、 @throws 、 @deprecated ,而這四種類型都不會為空。當一個「at-clauses」無法以單行描述完畢時,其續行該要以 @ 為基準做四個(或更多)空白的縮排。

這,當下我肯定不會,所以承諾她說晚上回家找我的好哥們請教。然後就剛沒多久,問我那位哥們不到 10 分鐘就給出範例答案啦。

閱讀全文 »

論述軟體三大基礎觀念-封裝、一般/特殊化 (繼承)、介面/多型

這是看到 PTT Soft_Job 版區一位網友的貼文:[請益] 我這樣解釋OOP對嗎?。原來我已在「FB-軟體設計鮮思維社群」針對此貼文已寫一篇文論述,在此邊我也把回文作個備存,然後再加上一些些心得分享。

剛入門所謂 OO → 連帶等同所謂「物件導向」觀念實作與設計觀念時,幾乎各類 OOP 入門書籍均會談論到此三大術語:封裝 (encapsulation)、繼承 (inheritence)、介面 (interface)/多型 (polymorphism)。看似簡單的術語,卻可能連多數鑽研多年實作的程式開發人員,還不容易真正體會這些觀念的意涵與作用。

即使入這軟體開發行業多年,仍會發現到,軟體大師們的著作,從最早期的 GoF 四人幫「設計模式 (Design Pattern)」,至近幾年「重構 (refactoring)」、「Clean Code」等著作,幾乎都是含繞在上述三大觀念的解釋與實踐。所以也就是說,這三大觀念可以說是要窮究一輩子的研究、思考與實踐力行的,它沒有絕對的標準答案,但也不見得好像很虛妄抓不到。每一段時期的經歷與學習,就可能會對其有著不同的想法與心得體會。

以現在個人入行軟體開發這行業約莫10來年,主要專職於軟體顧問輔導與教學,就以現階段綜合學習、觀察、反思與經驗等,來對這三大術語發表純文字的論述。可能又等 5~10 年後,當又有不同的體認時,再來對比現在的論述,作心得的補充或修正了。 :)


花了三個多小時撰寫這篇 PO 在 PTT soft_job 版,關於 OOP 的三個主要觀念:封裝, 繼承, 介面/多型。

這裡特別提醒下,程序語言用書很喜歡用「繼承」這字眼來解釋 OOP,其實那很容易誤導,常會用 父母生子 這種觀念看待。適切的用語用 "擴展 (extend)" 較適合。UML 稱之為 一般化/特殊化更是合理。

閱讀全文 »

創意確是來得比程式碼品質有價值;但好的程式碼仍是有意義的

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

前幾日在許多新聞電視台播放這則新聞:「牙醫預約APP 七年級生月營收20萬」。

的確很欽佩這位七年級生,剛出社會沒多久,就將自己的理想與創意實現,並因此而創造出公司的金流 (cash flow),立穩經營的腳步。

然後在看播放新聞的過程中發現到,喔,該 App 創辦人兼開發者,應是利用 GitHub 作版控 (version control)與維護程式碼的。這很正常更是值得鼓勵與借鏡,即使少數三兩個軟體人員,藉由雲端儲庫 (cloud repository)作版本管控,更能實行遠距協同開發與溝通,讓協同開發更形順暢。

然後又一瞥看到開發者撰寫的程式者,只是一小段而已,不過應該看得出在某一個方法 (method) 內撰寫了許多 if..then..else 的條件判斷陳述。

喔,這其實算是違背了「Clean Code」簡潔程式碼的原則。每一條判斷陳述可能是代表了單一的工作單元 (unit of work),當條件判斷陳述越多、變化越頻繁,越是難以維護。一般這最好是施以重構 (re-factoring),運用「萃取 (extract)」的技巧,分派單一工作至相對應的類別/方法 (class/method)內,讓程式碼回歸到簡潔易讀好維護的原點。

這讓我又再次思考一個問題:到底發揮創意並具體實現最重要,還是要求程式碼乃至工作的品質?

這幾年個人乃至於所屬的顧問團隊,可說都相當要求系統 (包括分析設計產出與程式碼)的開發至維護期間的品質,目的是為了讓開發更形直覺順暢,以及讓後續的維護更能應付變動,如此更能增進系統整體的價值。

但個人更是推崇 Maker 的文化,從發想到創意的實現,一切自造,需整合相關軟、硬體知識,並從過程中持續學習與修正不足之處。

創意的發揮來得比單一所擁有熟練的技能甚或品質更有價值!!

那回歸軟體領域,如此為了維繫軟體程式碼的意義何在? 這可真不容易回答!

閱讀全文 »

關於軟體需求變動的一個小案例思考

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

一個發生在昨天輔導單位的一個小小的案例,應該也可以藉此讓許多開發人員反思下...。

某一技術高深的程式開發人員 (就簡稱 PG)對一已進行開發至一半時間的專案,突然 User 代表 (關係利益人,就簡稱 User)丟了一個針對要計算折扣代碼的邏輯的需求進來,而且看來好像挺複雜的樣子。

PG 心態上不是很愉快,都已進行至一半,現在才突然有這樣的需求,需要為此多花一至兩天的時間來撰寫它,而這會影響到既定的上線時間。

嗯,我的判斷是當然會多花一時間,但不至影響到預定的時間。心態上的不適 (為何這麼重要的需求到中後期才提出來)遠比實作的難度大很多!

我能作的是什麼? (在這個極小型的專案我兼職擔任 PM),幫開發人員多爭取一天的休息時間,讓他們心理好過些。

然後昨天這位 PG 花了很多時間在撰寫相關這邏輯的實作,甚至很認真的透過 SA 與 User 提相關的問題。

嘿!這時刻我給他制止了。。

閱讀全文 »

軟體思維顧問

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

Personal