Gelis 技術隨筆-部落格

圖（一）、決戰 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支影片： 就像上面圖片裡現在所呈現...

前言 先前，在 .NET Standard 2.1 推出之時，微軟官方就已經宣告不支援 .NET Framework 4.8，且 .NET Framework 4.8 也被宣告為 Windows 上的最後一版的 .NET Framework，未來有任何新增功能（也許為了微服務／非同步／OSS…）等一些更進階的場景、也許透過語言支援、也許透過 Runtime Compiler 來支援，但是這些功能未來只會在 .NET Core 3.x 以後的版本中出現，也不會再像以前一樣，更新回 .NET Framework 裡。 這對開發人員來說，也許是壞消息、但也許是好消息。 在.NET Standard 2.1 中大約增加大約 3k 的 API，簡而言之、.NET Standard 2.1 增加了許多是 .NET Core 2.0 開始支援的 API，像是 ValueTask<T>、Span<T>、還包括許多在 .NET Core 2.1 ＆ Xamarin & Unity 才支援的型別。 更詳細的資訊可直接參考 terrajobst 的 Github： https://github.com/dotnet/standard/blob/master/docs/versions/netstandard2.1.md 也就是說，從 .NET Standard 2.1 開始，只支援在 .NET Core 3.0／Mono 5.4／Xamarin.iOS 12.16 … 等 以上的版本中使用，然而 .NET Framework 4.8 不再表列之中… 沒錯！就是不再表列之中，就是沒有！ 圖（一）、All .NET Standard Versions 圖片來自： https://github.com/dotnet/standard/blob/master/docs/versions.md 實際的測試下，如果你開一個 net472 的 Console 專案來參考 .NET Standard 2.1 的類別庫時，你連編譯都無法編譯。 圖（二）、根本無法編譯 有一種解決方案就是使用多目標編譯方式來通過編譯。 多目標編譯使用方式可參考下方： <Project Sdk="Microsoft.NET.Sdk">    <Prope...

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 因為企業內部真...

這次，於 2019/05/05 受新竹敏捷社群總舵主柯仁傑的邀請，在新竹敏捷社群我分享了一個關於 您的軟體架構夠敏捷嗎？ 的主題，在這個主題當中，我分享了我個人早期多年在專案開發上的系統設計相關經驗外，與最近這五年執行顧問時，替企業規畫與設計軟體架構相關經驗的分享，過程中，與觀眾有幾個共鳴點待我在下方娓娓道來。 軟體的快速交付≠有價值的交付 課程一開始，我提到了在十多年前，我曾待過一家軟體公司，在這個環境中我們嘗試創造出一個 0 缺陷的軟體架構，詳細的內容我在上一篇文章【 敏捷的軟體架構設計：可擴展的軟體架構 】裡有說明，這裡不再重述。 接著，我提到了現在也是開發流程+開發方法百花齊放的年代，只是 Agile／DevOps 特別為人所知而已，但在這個混亂的年代分常容易讓人無所適從，尤其時初學者，因為你所處的環境有可能已經追不上大環境中的變化與改變的速度了，但是你卻還是有很多東西要學，對吧？我的意思是，最讓人無所適從的倒不是技術的推層出新，慢慢的反而是到底是改怎麼做才是正確的？這部分我們以下在詳盡說明。 先前我曾聽過某大廠的 App 能夠在一天之內交付 20 ~ 30 次的版本，這對一家軟體公司來說，維運與開發之間必須非常的運作與整合完備情況下，再加上工具的熟悉度極高，才有可能將 CI／CD 持續整合+自動化部暑到如此境界 ，有許多軟體開發商無不卯足全力渴望達成此境界！ 但是據我所知，大部分大型購物網站、或者對外的訂票系統，事實上，他們在實務上只需要一天上一個至兩個版本便足夠了！ 如果您需要在一天之內上 20-30 次版的話，通常代表著您的開發流程可能是出了問題，比如：團隊與 User 可能存在著隔閡／開發人員或小組之間沒有共識+不清楚需求就冒然的修改程式碼… 等等。 我在這邊請大家思考另一個面向問題，就是，軟體公司究竟想要什麼？做專案+產品想要的是什麼？就是【獲利】！對吧？做這麼多，改變這麼多，去了解敏捷是什麼！最終目的，就是要賺錢，但是要賺錢，就得先思考如何【獲利】呢？因為你們在進行系統開發時一定常常遇到下面問題： 測試總是花費許多時間？ 軟體的修改總是牽一髮動全身？ 無法掌控的技術債？ 失控 的技術債？ 需求確定後，才可以開始寫程式？ 架構設計完成後？才可以開始寫程式？ 對了，看到這裡答案就呼之欲出了，公司要賺錢，就是要將『成本...

敏捷底下的軟體架構 圖片取自： http://m.001zf.com/newshow.php?itemid=696 前一篇，我分享了 您的軟體架構夠敏捷嗎 ？而我寫過許多關於架構設計的相關文章，但今天這一篇，可能是最難寫的一篇？因為，在（確定的需求／沒有 Deadline 的時間壓力下），寫程式並不件難事，對吧？那麼真正難的在哪裡？真正難的是在，有限的時間 與 資源內，發展出（符合客戶需要／為客戶產生價值）的商用軟體，且這個軟體須具備一定的可延展性、擴充性、可維護性，並在企業的可控制的成本範圍內，或者，在敏捷的每一個迭代開發裡，逐漸發展成為客戶所需要的軟體，對吧？軟體公司為企業創造與量身訂做軟體也是為了賺錢，若軟體開發所投注的成本成為無限的話，虧本的生意沒有人會想做的。 傳統的軟體開發產生的架構問題 圖（一）、傳統軟體開發的前身 SDLC (Software/System Development Life Cycle) SDLC 是早期用以描述一個資訊系統，從無開始規劃、分析、建立、測試、直到最終完成的一個過程。看似無任何問題，事實上，它也運作了幾十年，似乎也確實沒有任何問題，許多團隊也是能夠創造與交付出符合客戶需求的軟體，可是，慢慢的，許多團隊與軟體公司漸漸地發現，當需求變動性高、需求不確定因素高的時候、或者在許多實際的市場機制下，軟體的『開發』與『發展』逐漸與慢慢地跟不上時代的演進 與 市場的變化了。這怎麼說呢？因為當不了解需求、不了解客戶想要的價值時，你所花的（工／成本）絕大部分是浪費的，因為軟體開發越到後期修復的成本是越高的。 以傳統瀑布式開發來說，我得先做完需求分析、才可進行系統的設計，而當系統設計完成後、才可開始進行系統的（程式碼撰寫／Implementation／實作），但問題來了，什麼叫做【系統設計完成】？難道我得在一開始，弄清楚客戶的所有需求？因為系統設計完成、也代表架構設計完成了？如果軟體架構可以在程式碼撰寫前就確定，這不就代表需求必須固定？問題是…. 這是不可能的….. 這其實是一個【雞生蛋、蛋生雞的問題】 圖（二）、雞生蛋、還是蛋生雞？ 0 缺陷的架構 = 0 擴展的軟體架構 在早期，曾經有團隊／軟體公司 將所有功能均提供在軟體產品裡，也就是大雜燴的方式，嘗試滿足市場各種不同的需求，筆者很早期待過的軟體公司也還真的經歷過這樣的模式，而在當時，...

前言 上一次的文章【 ASP.NET Blazor 怎麼處裡狀態？ 】中，筆者說明了幾種在 Blazor 上保存狀態的常見用法，但是當時筆者無法在 [YourProjectName].Client 的專案裡安裝『Microsoft.AspNetCore.Http』、『Microsoft.AspNetCore.Http.Abstractions』、『Microsoft.AspNetCore.Http.Feature』這三個套件 均無法安裝成功，後來我發現，無法成功是正常的，這因為 [YourProjectName].Client 是執行在 browser 的沙箱(Sand box)裡面，試想，這三個套件都是相依於在沙箱裡，而這個沙箱內又以 Mono Runtime 來執行 .NET Standard，如果 .NET Standard 本身不支援那個 API 也無法執行對吧？更何況又在 browser 的沙箱環境中。這更不用說 Microsoft.AspNetCore.Http.Abstractions 裡還參照了在 Mono Runtime 裡不支援的 advapi32.dll & kernal32.dll 等 就算技術上可行，安全性其實也不允許你在沙箱內部存取外部 OS 資源。 也就是說， 上次的那個作法是錯誤的 ，我們根本就不應該在 [YourProjectName].Client 裡面安裝那三個套件，應該回頭過來思考，我今天的需求是，要從 browser 將 COUNT 內容傳遞到 Server 上，並保存下來！ 也就是說，我們應該將 [YourProjectName].Client 這樣的專案當作是一個執行在前端browser 中包含 Front-End Framework 的 SPA 應用程式，這麼一來，是不是就清楚多了？ 因為 Client 是執行在 Browser 中， 若不是 Blazor ，傳統 SPA 作法也是透過 JavaScript 執行 Ajax 的 Call Back 呼叫，將 Count 傳遞至 Web Server 上保存下來對吧？ 所以，Blazor 也會是相同的做法。 專案結構 正確做法是什麼？ (1). WebBlazorStateTest1.Client 的 Counter.cshtml 在 Counter.cshtml...

前言 上一篇 什麼是 gRPC ，筆者大致介紹了 gRPC Service 的基本概念，這一次，我們就來小試一下身手，撰寫一個 Hello World （迷之音：嘗試新技術時，總是得先來一個 Hello World ～我不想違背這良好傳統阿阿阿阿） 使用環境 Visual Studio 2019 .NET Core 3.0.100-preview3-010431 開始進行 撰寫 gRPC 除了先準備好基礎環境、選定一種 作業系統／ 程式語言 Language 外、（Framework／SDK／Runtime）等環境備妥後，就可以開始撰寫， (1). 開始撰寫 gRPC 第一步就是先定義 .proto 協議了 上一篇筆者提到，gRPC 的 Server 與 Client 必須使用相同的協議才可進行溝通，一般來說，你應該使用 protoc.exe 編譯器先行編譯過 greet.proto 協議檔，並產出 C# 程式碼檔案後才可繼續，而在 Visual Studio 2019 裡，拜 MSBuild 之賜，已經有人預先寫好 .Target 檔案了 （什麼是 MSBuild ？什麼是附檔名 .Target 檔案可參考： MSBuild .targets 檔案 ） 筆者先撰寫一個 SayHelloWorld 方法如下： 在協議裡，除了在 service Class 撰寫要公開存取的方法外， 必須在提供『傳入訊息型態』、『回傳訊息型態』 ，這邊我先定義兩個 message，一個是『 HelloMyFirstgRPC 』、另一個是『 HelloMyReply 』 在撰寫 proto 協議檔時，建議先決定 message 回傳型態與傳入的型態，那麼 Visual Studio 2019 會有 InteillSense 的完整支援。不得不說 Visual Studio 2019 在 .proto 協議編輯上的支援已經算不錯了。 注意： 一般來說，Visual Studio 2019 會在背景裡自動編譯 .proto 協議檔案，但始有可能不會有任何提示，所以您也可以自行使用命令列工具進行手動編譯，如下圖，若編譯失敗會出現錯誤訊息，如下圖顯示 return 關鍵字錯誤： protoc.exe 編譯器 & 相關 MSBuild Tools 會隨著 NuGet 套件在 Vis...

圖片取自： https://grpc.io/docs/guides/ gRPC 是什麼？能吃嗎？ 在安裝了 .NET Core 3.0 之後，眼尖的朋友應該會發現，在新增 ASP.NET Core 網頁類型專案裡，會看見一個 gRPC Service 類型的專案，其實它也不是什麼很新的東西，早在十多年前 Google 就使用這樣的 RPC 協定進行一些大量的可靠性微服務的存取，聽到這，難道現有的 Web API 不可靠嗎？其實不是的，它主要用在移動設備等提供高效簡單且跨平台的通訊與熱插拔的驗證機制。 gRPC 的運作原理 gRPC 顧名思義，是種基於 RPC 的通訊協定，不同於 Web API 走的傳統 HTTP 基礎協定，它有點像是 Socket ，但應該說是基於 Socket， 或精確地來說它是基於 HTTP/2 的協定 ，gRPC 是種協議緩衝協定，它必須事先定義 IDL (Interface Definition Language) 描述檔，看到 IDL 對於一些熟悉 COM／DCOM 的朋友一定非常的熟悉，對！沒錯！就是類似的東西！但，這邊的 IDL 是用一種副檔名為 .proto 檔案來是先定義在分散式環境中，要傳輸的序列化結構資訊，當然它也可以跟 JSON 一起使用。 也就是說，要使用 gRPC 您必須先定義 .proto 協議，然後透過 Compile 的支援，編譯成特定語言框架。而很高興的是，C# 也支援了，然而其實根據官方的資料顯示，C# 應該在 .NET Core 2.1 開始就支援了，只是到了 .NET Core 3.0 才有樣版的支援。 而使用 gRPC 的協議緩衝區的服務可以做到 Stub 的機制，也就是說，它就像是許多 RPC 一樣，Client 在呼叫 Server 端時，其實是對 Stub 進行叫用，Stub 在這就像個緩衝區一般，但更細部的說，應該是一個遠程服務的替身，這應該又讓許多熟悉 COM／RPC 通訊的朋友覺得熟悉了起來，是的！沒有錯。 在 .NET Core 3.0 裡使用 gRPC 目前支援 .proto 擴展為 gRPC 協議緩衝區的編譯器只有 .NET Core 了 ， 根據 Github 上的說明 .NET Framework 4.5+ 以上或 Mono 4+ 以上也可支援，而 gRPC 也完全的跨平台。要在 ....