Gelis 技術隨筆-部落格

敏捷底下的軟體架構 圖片取自： 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 也完全的跨平台。要在 ....

圖片來源： https://www.magzter.com/articles/488/256119/5a2a9554df1c0 什麼都要敏捷？ 近年來，敏捷概念幾乎已經深入人心，不光是軟體業談敏捷，慢慢的可以看見各行各業也在談敏捷的思想，前幾次的 Agile 活動裡，不再像以前一樣，只會出現軟體相關產業的面孔。為什麼敏捷思想開始深入人心？其實是因為『變化』不只存在於軟體產業，要面對未來、面對變化、面對挑戰，唯有敏捷以對，隨時快速地調整自己，提升自我能力，靈活的面對這些改變，隨時再出發、隨時再出擊。 測試理念的崛起 測試可說是近十年來，發展最快速的軟體開發理論之一，早期的軟體開發將測試定義為軟體開發生命週期裡的其中一個階段，通常後期進行，也就是當軟體完成到某一程度時才進行，但是當軟體完成到某一程度時，也代表著你要對軟體做任何的需求改變、功能的改變、又或者是新增功能，所需的成本可能是非常的高的，這也是傳統的瀑布式開發慢慢為人所棄用的最主要原因之一，因為人們慢慢地察覺到，軟體的『測試』應該與『開發』這件動作密不可分才是，又或者說，測試其實應該算是軟體開發的其中一個動作，而且是非常重要的一個動作，因為經由測試，你曾能夠確認軟體正常運行無誤、經由測試才能確保軟體能夠被交付、符合客戶需求 + 如預期的運作。 而早在十多年前，TDD, Test Driven Development 的大師 Kent Beck 所撰寫的 TDD by Example 一書就已經提到這樣的觀念，先撰寫測試的程式碼 (Unit Test)，在撰寫 Production 的程式碼 從 TDD／ATDD 談傳統 SDLC 的缺陷 在 ATDD 裡提到了左移測試的 V-Model 模型，這個被討論了十多年，只是不幸的是左移這件事常常被誤解成只是將測試移轉至左側，而忽略了由上而下的測試進行。然而，當然，許多的軟體開發者也都知道，在軟體開發生命週期越後期測試所發現問題的時候，修復的代價就越高，這個狀況幾乎可以解釋為傳統 SDLC 的缺陷了，所以，這表示什麼？這意味著在軟體開發生命週期裡應該盡早進行測試才能夠降低這些風險，因為在這些年來因為沒有盡早測試而產生的問題如下： 測試人員可能沒有參與軟體的初始規劃，通常導致測試對系統了解有限+最後分配給測試的資源又嚴重不足 許多需求，架構和設計缺陷都沒有再一開始被『發...