Gelis 技術隨筆-部落格

圖片取自： http://www.zhougong.com/qita/73778.html 其實，我算鮮少談論這種比較不談程式碼 & 非技術性的議題，最近，常聽到周遭朋友在網路上談論 & 臉書 PO 文 或是 撰寫相關文章談論著架構師相關的議題，也有先前 MVP 的朋友們公司在找架構師，雖然一直都找不到 XD，但稱職的軟體架構師真的不好找。 我的工作經歷 而我從事相關的軟體開發工作已經有好長一段時間，從 1998 年畢業到現在，我也是從小 PG 開始，過程中經歷 SD、SA、RD、PM、Program Leader ，而最後又回到 SD 的角色、後來選上 MVP 後因緣際會地到了集英信誠擔任顧問角色一路到現在，現在除了協助客戶開發流程的導入外、我也協助軟體架構設計規劃，而因為我接觸的都是實際產業界的狀況，多半也是客戶實際面臨的棘手問題，所以不見得你可以直接套用你手中現有設計的軟體架構，因為有的客戶是現有系統有效能瓶頸希望你改善、有的是有套前人留下的架構但是不知如何團隊協作加速開發、有的是系統雜亂不堪+疊床架屋後遭遇嚴重 BUG 不知道該怎麼辦！所以，你沒有固定招式可以套用在所有的客戶上，你得因(人／客戶)而異的規劃全新的方式(當然都是自己的經驗加以融合後的結果)，所以每一次都需要一個完整的 需求了解 => 現實情況拿捏 => 客戶環境 => 模擬情境 => 與客戶討論與改善方式建議 => 接著才是進行的方式、當然也有談不攏根本不會合作的，但這邊是說明客戶自己也想改善的，並且客戶採納我的建議的。 當然，這邊有點扯遠了，改天也許我可以寫一篇顧問的甘苦談，但此篇文章我先把重點先放在『軟體架構師』如何養成？我以自身的相關經驗來說明， 先說明有些是我個人經歷，並不代表每個人都應該是如此，因為凡事沒有絕對的。 因為我前一份工作是系統設計師，專職便是軟體架構設計，當時便是公司內部主要 C# 與 ASP.NET MVC 相關課程的主要 Trainer 講師 + 同時也是幾個專案的負責人 兼 架構設計人員，也有寫作部落格習慣，也因此在當時因緣際會選上 Microsoft MVP，而後的顧問工作期間，也是幾個客戶的架構設計顧問，那麼，這邊我稍微的娓娓道來我這幾十年來、我自己的改變是什麼？ 軟體架構師可以養成？ 等等？軟體架構師可以養成？對了...

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

前言 先前，在 .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...