Gelis 技術隨筆-部落格

為什麼我說在撰寫程式之前，還是先做個簡單的分析比較好？ 我們可以從討論中獲得共識，但你跟你的需求獲得共識了嗎？ 前言 上個禮拜，我在公司對新人進行教育訓練，我依舊按照我原來進行訓練的步驟開始，先了解主題與內容，也就是新人想學習得內容？比如是前端？或者是後端的開發等等。接著是新人的程度到哪裡？如果假設我是要教 C# 與 ASP.NET Core MVC 的開發，那麼我得先調查新朋友是否已經撰寫過 C# 以及對 OO (Object Oriented) 了解的程度到哪裡？再來，就是從我們一般進行專案開時，所所有會使用到的技術來排定學習的優先順序，當然了，也考量學習的新朋友目前所擔任的角色。 學習是需要被客製化的 再回到本文想要講述的重點，因為每一個人的基礎都不同，已經熟悉的技術內容都不同，所以經過客製化的訓練內容也會有些不同。 而我們現在談的是軟體專案開發，既然是專案開發，那麼開發的內容(產出的內容程式碼)是來自於使用者需求，所使用的技術只不過是幫助我們去勾勒出『使用者』需要的『成品』（也就是成運作+並達成使用者標的與期望解決的問題）的軟體最終成果（也許是網站 Web／APP／..Others）， 也就是說，使用何種技術只不過是種手段，但是你有沒有 Catch 到使用者真正的期望與需求那可能是另外一件事情。 在真的開始寫程式之前，建議還是做個簡單的分析吧！ 在開始之前，我隨口問了一下新朋友，你知道 OOAD 嗎？就是也可以拆解開來分別談 OOA/OOD ？ 結果新朋友告訴我，她只有聽過 OOP 而已，沒有聽過 OOA 與 OOD? 我聽到之後非常的驚訝，因為這位新朋友再來公司之前去恆逸上過課而已，也許已程式開發為主的課程並不會提及這些，也有可能軟體開發內容層面範圍較廣無法全面提及也是實屬正常。 我告訴她，其實在台灣目前的產業裡，也不太重視分析／設計這兩個階段，但是我個人反而比較重視這想個階段，但並不是說我不重視使用的技術 & 軟體架構設計，因為使用哪一種軟體架構設計／Patterns 是來自你的『使用者需求』，像是幾年前，我曾經寫過一篇文章：『 從使用者需求、談軟體架構設計 』這篇文章所講述的內容一樣，一切都是來自你的需求。 而有部分 Bug 亦是從需求而來，而從需求而來的 Bug 往往最難修改，可能得翻掉架構也說不定。 圖（一）、從需...

圖（一）、LOGO: 基於 Clean Architecture 改畫製的 3D 立體圖形 前言 其實，我應該不止一次討論過這個主題，關於 Clean Architecture 的 Plug-In 的軟件架構，在〔軟體開發之路〕或先前所開的實體課程〔跨平台的 Web API Framework 框架設計〕中討論過、也實際帶著學生實作過這樣的架構。 何謂插件式的軟件架構？ 圖（二）、從裝置定義 IDevice 介面來演示 Plug-In 插件式軟件架構 如上圖中，不管是 Quantum 硬碟 還是 Pioneer DVD 都是透過 IDevice 介面來實現硬碟 IHardDisk 的主要功能 或者是 透過 IDVDDeive 來定義 Pioneer 光碟機必備的功能，然而最好能夠透過 DI 注入實作，所以系統的靈活度非常高，組件頂多對介面相依，實作輕易的被抽換。 或者是利用 AOP 模式賦予驗證機制或使用匿名存取，優點也是可抽換性非常高，異動原有功能也不須異動到原有的程式碼。 圖（三）、透過 AOP 賦予驗證機制 先前，我在曾在軟體開發之路裡 PO 過關於在 Clean Architecture 的圖形中，在架構圖的右下角的 Use Case Output Port/Use Case Input Port 到底指的是什麼？而且事後並不只一次也有其他的學員或朋友問我相同的問題，而這其實可由 MVP／MVVM 來講起，為什麼呢？ 圖（四）、The Clean Architecture 這其實可由 MVP／MVVM 來講起，為什麼呢？因為在 Clean Architecture 或是更早期的【洋蔥式架構】或【六腳架構】都是由外圈而內相依，內圈可獨立存在。 但問題來了，如果你用 MVC 或是 MVVM 來實現 Clean Architecture 軟體架構的時候，雖然 MVC 本身職責分離，由 Controller 負責協調 View 所需要的 Data，但 View 與 Model 仍然有某種相依性程度在，也就是說，仍然有可能因為 View 的改變而牽連 Model 必須跟著改變，而這違背 Clean Architecture 原本的精神。 好....那所以，該怎麼辦呢？就是在 View 與 (Model/Use Case) 之間，加上一個 P...

圖（一）、決戰 OOAD 線上課程 LOGO 這個課程我從今年的八月開始錄影，但是因為家中有小孩剛滿一歲，因此假日也得要分擔家務也培養親子關係，因此在時間很有限的情況下，我已經只有六日的時間了，扣除掉陪孩子的時間後，所省也沒幾個小時，所以這一搞就搞了四個多月才完成。 但決戰 OOAD 課程的章節也非常的多，從理論說明、到為什麼使用 Modeling 來開發系統？OOA／OOD 的介紹、到 UML 的實際的應用面也是使用一個實際的線上房貸申請的需求來當作例子，課程是原汁原味地將先前我所開過的實體課程程，除了完整呈現一遍之外，事實上、我還加了一些先前 講過的跨平台開發的 Clean Architecture 的例子，並在架構設計的部分與 UML 的設計產生關連，最後實際的撰寫程式碼，當然、程式碼與 Modeling 設計產生關聯也是本課程的重頭戲之一。 曾經朋友有有再問，為什麼你這麼熱衷於 OOAD？其實，有一部份原因是，我覺得近7-8年有一種很弔詭的現象，我們知道軟體開發的世界進步非常的快速，方法論的不斷的演進，瀑布式開始、敏捷、看板，近來也盛行 TDD 開發方法、或是 DDD 領域驅動設計、但是 TDD 或者是 DDD 我會覺得比較像是『（外功／招式）』，而這些招式比較需要足夠的軟體開發基本功，華麗的招式往往更需要更強的基本功來支撐，就像我常常在說的，如果你是用 OO 的語言在開發系統(像是 Java/TypeScript/C# 等等)，那麼你在（分析／設計） 的時候一定得是採行物件導向的分析設計方法，就是俗稱的用物件的角度來看事情，那就是本課程裡所謂的 OOA／OOD，所以如果 TDD 或 DDD 外功、那 OOA／OOD 就是蹲馬步了，試想，如果你連蹲馬步都蹲不好，這些招式怎麼可能練的扎實與真正了解其中奧妙之處呢？還有可能會內傷呢！這就像天龍八部裡面，一群武林人士進入到靈鷲宮看到牆壁上那高深的武功就狂練、基本功與內功不足的不久就立刻走火入魔是一樣的道理。 圖（二）、武學中往往招式最吸引人 圖（三）、但『基本功』才是最重要的 這次，我開立這樣的課程也是希望帶給大家從入門到進階的 OOAD 系列完整的從無到有的系統分析設計再加上真的實作。 說真的，我還真不敢相信我將它全部錄完了！這個課程一共有 38支影片： 就像上面圖片裡現在所呈現...

disclaimer 圖片取自： https://jstermask.github.io/anycode/index.html 前言 之前曾試用 Astah Community 就被其強大的功能所吸引，而且期繪製 UML 圖形的（方式／Style） 比較符合 UML OMG 官方組織的規範，即便在我已經慣用 EA 的情況下，我仍然有時候，有些圖形我會使用 Astah 來畫。 問題描述 因為 Astah 是由 Java 所開發，即便 (UML／Professional) 版本支援【Export C#】的 MDA (Model Driven Architecture) 功能，但匯出的 C# 檔案總是與 C# 3.0 之後的語言版本格格不入，因為熟悉 C# 的開發人員都知道，C# 的 get and set accessor 到了 C# 3.0 時代已經加入了 Auto-Properties 的功能，也就是說，我可以將原先比較囉嗦的寫法： 縮短改成如下，這叫做 Auto-Properties 但是，當我們使用 Astah Professional 所提供的 Export C# 功能時，如下 Class Diagram 中的 Account 在我們使用 Export C# 功能匯出 C# 程式碼時（如下視窗可讓我們自由選擇Class） 但美中不足的是，即便你有勾選『Export properties as C# 3.0 automatic properties』但是透過 Astah Professional 所產生的 C# Class 檔案中每一個 Properties 卻還是如下： 由此可見，Astah 對於 C# 的支援並不是那麼友善，又或者說，Astah 所支援的 C# 根本還停留在 C# 1.0 的年代，而且不光是 Astah 有這個問題，還有許多 UML Case Tool 對於 C# 語言的支援都不是那麼友善，包括 EA 也是，這我就不一一點名了。 對 C# 支援最完整的還是 Visual Studio 提供的塑模化 Modeling 的功能了，可惜的是官方到了 Visual Studio 2017 時就拿掉了 Modeling 的功能，理由是塑模化的功能很少人用，但這不能當作理由吧？XDDD 因為企業內部真...

前言 最近，經由前前公司的同事介紹下，他目前所處的單位有一個教育訓練的需求，該需求是這樣的： 一、團隊中有許多人從 notes 轉換到.NET開發不久，目前工作為 SA ，但是對於從 SA 工作到 SD 的銜接總是有點卡卡的。 二、團隊中現有 SD 對於 ASP.NET MVC 的開發不甚了解，希望藉由課程能夠順便讓其了解在 .NET 平台上能夠做到那些事情 (泛指在 Architecture Design 上，.NET 平台上能提供什麼？) 三、但是聽眾中大部分為 SA，所以希望能從系統分析開始講，一路到設計、實作，希望是一個一條龍的課程。 四、加上目前團隊正在大量地使用 UML 作為系統分析的 notations，所以，希望系統分析 SA 的課程的部分已 UML 為主。 恩，所以此課程名稱最便成為：『ASP.NET MVC 與（SA 系統分析／SD 系統設計）與 OOAD/UML 軟體系統開發課程』，課程名稱非常長吧？沒錯！XDDDD 而且內容非常 非常 非常硬….. 因為課程必須使用真實的例子，最好是客戶目前實際地 Case，而且要從 SA 開始 (教如何繪製 Use Case + Domain Class Diagram + Sequence Diagram)、到 SD 該如何讓 UML 與平台 & 語言有關？MDA 是怎麼回事等，所有繪製的 UML 圖型必須能夠與程式撰寫銜接上喔，因為許多人會畫圖，但是，你畫的圖能寫程式嗎？多數人是不清楚的，而剛好，我對於 UML 中的 SA 與 SD 如何銜接，剛好有些研究，而且最近五年來我手上的所有專案均是這麼做的！我所畫的圖型絕對可以直接產 Code，而且非常非常的清楚，對我而言，這樣的設計方式我已經行之有年，於是我很爽快地就答應了這一次的企業內訓課程，雖然這個課程真的非常硬，哈哈，我說非常硬的原因是，在這十天的課程過程中，到最後一天，我必須帶著學員真的撰寫出一個線上房屋貸款申請系統！要可以申請，對你沒聽錯，課程結束，要真的把一個系統做出來…. 這就是我說非常硬的原因。不過，還好，我做到了！哈哈 對本文內容目前已錄製成線上課程： 決戰 OOAD 系列課程 、有興趣的讀者，可參考： 課程連結 進階使用案例分析技巧 在上一篇文章中『 從使用者需求，談架構設計 』我提到了軟體專案的核心架構必須由使用者需求出發，因為...

前言 軟體開發本身是一個複雜的工藝過程，牽涉到各種領域技術，一般我們所聽到的軟體架構設計可能都只著重在軟體系統架構本身，比如：如何妥善的分工、如何解決開發上的各種問題、使用哪一種 Design Pattern 來解決問題、如何快速開發等等，只不過，真正有用的軟體是對客戶有用的軟體、能替客戶解決問題的軟體，才是真正有價值的軟體。 如果，您有非常妥善的軟體架構設計、並整合的 CI／CD 自動化整合測試部署、交付流程，也整合了 Containers 等相關技術，但是 CI／CD 過去卻不是使用者所想要的軟體，那你頂多只是做到了可快速的不斷的交付軟體直到客戶滿意為止，但，如果一開始的需求方向就錯誤了，那就不是 CI／CD 自動化整合測試部署、交付流程所能夠解決的問題，因為你的核心架構可能都需要重新翻寫。 當然，並不是說上述架構設計、自動化測試整合部署流程不重要，架構設計、自動化測試整合部署流程固然很重要，只是，相形之下，做出客戶需要的軟體，後續的各種軟體架構設計、自動化測試作業也才有真正的價值。 關於軟體架構設計 事實上，真實世界中的軟體架構設計應該必須由使用者需求出發，正確收集到使用者的需求，也才能夠正確地做出最佳的架構設計，就專案而言，所以，如果您在分析、與紀錄使用者需求所使用的方式，能與開發團隊相同，且一致的語言 (透明化)，這一致的語言可能還包括，你在分析階段所以使用的 notations 表示法，甚至到您開始做系統設計 (System Design) 所使用的 Architecture documents 、甚至 implement 所定義的 （Programming rule/Coding Standard）等，都在這個的範圍內，也可以說，如果您分析工具如果是建築於團隊開發的共同規範之上，那麼不管你們是團隊進行內部溝通（SA對SD／SD對PG），或是與使用者溝通，都可以將 Gap 降至最低。 在我自己的開發團對裡，我們取用 UML 部分的圖形與 notations 來使用，若您運用的恰當，它可以幫助你在分析使用者需求時，釐清、切割清楚什麼是使用者最關心的，因為，這其實都會與你之後的架構設計息息相關。 為什麼我這麼說呢？ 我下面分幾點為各位說明： (1). 在進行架構設計時，如果要避免「過度設計」，使用 UML 的 Boundary 可明確規範出哪些是系統內、哪...

最近筆者有對公司內部上一些(UML塑模設計 使用 VS 2010) 的相關課程，課程中筆者介紹UML的基本概念與Use Case Diagram基本的Notation使用方式，課後將一些資料再進行整理一下成此篇文章。 在使用Visual Studio 2010進行塑模設計時，有時會以UML類別圖來產生程式碼，且再進行反向工程時會使用現有程式碼進行塑模的建立，以方便檢視現有架構。但這些功能並不是內建在Visual Studio 2010中，必須安裝Visual Studio 2010 Feature Pack2才可以。 在安裝了Visual Studio 2010 Feature Pack2主要是使我們可以進行： 從 UML 類別圖 產生 程式碼 (Generate Code)。 從 程式碼 產生 UML 類別圖。 可匯入經由 XMI 2.1的格式所匯出的UML 類別圖、循序圖 和 使用者案例圖。 建立和檢視從工作項目到模型項目的連結。 開始支援為 ASP.NET Web、C 及 C++ 專案產生相依性圖形。 可以建立和驗證 C 與 C++ 程式碼的圖層圖表。 可以撰寫自訂程式碼以建立、修改和驗證圖層圖表。 安裝完成Visual Studio 2010 Feature Pack 2之後我們便可以將分析完成的UML Class Diagram使用『Generate Code』產生程式碼，為演示這樣的一個塑模的設計流程，我們以一個簡單的Shopping網站為例。範例中會使用一些簡單的OOA & OOD的分析方法。 在進行塑模設計之前我們先來看一下這個Shpooing網站的Scenario (情境)： 顧客至Shopping網站購物，首先會瀏覽型錄，決定商品後放入購物車，結帳，並填寫送貨單，包含送貨地址、收件人等資訊，始完成訂購。 接著： (依照上方情境畫出Shopping 的Use Case) 一般來說使用OOA找出Domain物件的分析方式就是直接在Use Case裡找出所謂的 『名詞』 物件，此又俗稱名詞分析法，這是一個比較簡單的方式。 在顧客Shopping的情節(Scenario)中，我們可以找出會有『顧客』、『購物車』、『商品』、『交易紀錄』、『送貨單』...