Gelis 技術隨筆-部落格

圖片取自：https://stackoverflow.com/questions/5513708/vs-extensibility-architecture-package-api-visual-studio-library 前言 記得，在去年的 Taiwan .NET Conf 2019 的分享裡，我分享了一場『該準備從 .NET Framework 4.x 遷移到 .NET Core 3.0 的嗎？』因為分享的當下 .NET Core 3.1 還未推出，而在分享前，我除了思考當前企業所面臨的挑戰外，心裡也迸出一個想法就是，我何不撰寫一個能夠將 ASP.NET MVC 5 的專案直接轉換為 .NET Core 3 專案的擴充套件呢？因為一直以來，我都有在涉獵 VS Extensibility & VS Package 等開發，自身也有撰寫一些 VS 擴充套件，像是 MyORM Extensions  ，也有推出 C# Project Templates 線上課程『 團隊開發系列-設計符合團隊的範本精靈 (Project Template) 』等等，也有上架在 VS Marketplace 上，於是在這場 Session 開始前兩個禮拜，便著手開始撰寫開發這個套件。 下方為當時的 Slides： 該準備從 .NET Framework 4.x 遷移至 .NET Core 3.0 了嗎？ from Gelis Wu 架構規劃 但因為時間非常有限，而我又必須先做出一個雛形，不過我希望在 VS 上的操作模式是：【我可以任意在任何一個 ASP.NET MVC 5 的專案點滑鼠右鍵隨即有個選單 "Convert MVC5 to .NET Core 3"】的 MenuItem 因此，我需要單鍵就可將 ASP.NET MVC 5 的專案轉換成 .NET Core 3 的專案類型。 關於 VS Pacakges 要做到這件事，不單單是像 MyORM 透過 IWizard 介面與 Project Templates 就可以實現，VS Extensibility SDK 中可開發的擴充套件提供了下面幾種類型： Analyzer  Project Templates  Item Templates  To...

圖片取自： https://home.gamer.com.tw/creationDetail.php?sn=2461568 前言 最近擔任某產業的 Redis 導入的執行顧問，我的任務就是，協助將 Redis 導入在既有的系統裡，在這個顧問案裡面，我遇到的挑戰是： 現有系統使用某產品進行開發 （好處是個系統共用此平台 Platform 提供的服務／壞處是某處出現問題就會全部一起死） 現有系統使用 .NET 4.0 的 Object Cache、所以要全部上 Redis，但是 Object Cache 是撰寫在該產品平台 Platform 內 Kernel 所提供的功能之一， 我得協助修改核心 Kernel 的 Cache Provider 另外是，系統為 ASP.NET WebForm ，所以許多存放在 Cache 內的資料均為 DataSet（基於一些原因我無法全改為不使用 DataSet）， 但因為我們知道 DataSet 並無法直接序列化轉為 Redis 可接受的格式，所以我得做些手腳以協助將這些資料轉換為 Redis 可以接受的格式 有上千隻程式運行在上面、必須一氣呵成！ 包含伺服器主機架構規劃 [建置 HA 高可用性架構]（必須購置新主機），所以也包含硬體規格建議等等 開始 這個案子在開始之前，最麻煩之處、也比較有代表性工作在於： Code-Review 包括現有平台 Platform & 子系統 改寫現有平台原始程式碼 & 包括最主要的 Cache Provider 以隔離測試（Isolation Unit Test）方法來進行改寫 進行 Code-Review 的部分比須帶著團隊來進行，當然包括 IntelliSys 平台的維護者，因為我需要了解現有的架構規劃、現有的 Cache 的使用情況、與現有 Cache 策略使用規劃等等、接著就是評估修改的幅度 與 範圍 ，因為程式修改的部分還是得以專案形式來進行，我還是會估一個類似 WBS 的工時並提供給客戶。 實際進行時，我大約花了 1 天的時間，對！幾乎一整天的時間，看了整個 IntelliSys 幾近所有的程式碼，因為為了較精準的估花費時間，也是因為客戶要求。第二天便開始架設 Redis 環境，第三天開始修改程式碼。 以 Unit Test 方式...

圖片取自： https://2.blog.xuite.net/2/8/9/b/11597010/blog_3502284/txt/218534111/5.jpg 前言 在前一篇文章『 您的軟體架構夠敏捷嗎？（二）- 持續演進的軟體架構 』一個持續演進的軟體架構我們其實做到一半而已，而在上一次，我們針對一個 ATM 自動櫃員機 的需求做了初步的分析，注意了，只是個『初步』的設計，這個設計其實還看不出來程式會怎麼寫，但敏捷又不希望我們在初期進行過多的設計，但是這不代表我們完全不設計啊？這一點我在第一篇文章：『 您的軟體架構夠敏捷嗎？ 』有特別禪述，這裡就不再說講。 下面，我們就繼續將這最後一塊拼圖給完成吧～ 測試先行的軟體架構 (1). 單元測試的最小粒度 在這裡，我們使用 TDD (Test Driven Development) 為主要的開發方法，TDD 是先寫測試、爾後再撰寫實際的程式碼，這部分我想會讀到此篇文章的讀者們應該都清楚這個部份了，還不清楚可參考訪間相關的 TDD 測試驅動開發相關說明，本篇就不再詳述。 重點來了，既然是撰寫單元測試 Unit Test、那麼單元測試不就是寫一段程式碼、來去測試一段程式碼嗎？其實這樣說並不完全正確喔！如果你今天是先撰寫產品代碼、爾後才撰寫測試的程式碼（當然這就不是 TDD 了）這樣說或許還算正確，但是 TDD 指的是一種『開發的方法論』，不單只是撰寫一段程式來測試另一段程式那麼簡單， 因為許多的開發者一提到『單元』測試，就認為單元就是指一段程式碼，但其實不是的， 這裡的單元指的是應該是一個『行為』的『單元』，它是一個獨立的、可驗證的行為。它必須對系統產生可觀察的影響，而這就是我們這裡定義的單元測試的最小粒度，當然，同樣為確保測試的獨立性它又不與其他的行為有耦合情況發生。 (2). 要怎麼測試先行？ 很多教你的 TDD 沒有人在講 UML 啊？沒有關係，我這邊慢慢教你怎麼開始？ 要開始撰寫測試先行的程式碼，我們也得要知道這個系統到底要要幹嘛？對吧？根據前面的 Domain Modeling 就是我們這個系統目前的全貌的樣子，當然這個全貌還不清楚，但最少有個基本的方向，而且方向在第一個最小可行性產品的增量是可以被評估出可以做出什麼，對吧？而我們一開始，也沒有花太多的時間，進行這些 UML 的設計，對吧？算一算，我這裡繪製前面那...

圖片取自： 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 可能存在著隔閡／開發人員或小組之間沒有共識+不清楚需求就冒然的修改程式碼… 等等。 我在這邊請大家思考另一個面向問題，就是，軟體公司究竟想要什麼？做專案+產品想要的是什麼？就是【獲利】！對吧？做這麼多，改變這麼多，去了解敏捷是什麼！最終目的，就是要賺錢，但是要賺錢，就得先思考如何【獲利】呢？因為你們在進行系統開發時一定常常遇到下面問題： 測試總是花費許多時間？ 軟體的修改總是牽一髮動全身？ 無法掌控的技術債？ 失控 的技術債？ 需求確定後，才可以開始寫程式？ 架構設計完成後？才可以開始寫程式？ 對了，看到這裡答案就呼之欲出了，公司要賺錢，就是要將『成本...