您的軟體架構夠敏捷嗎？

圖片來源：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 的缺陷了，所以，這表示什麼？這意味著在軟體開發生命週期裡應該盡早進行測試才能夠降低這些風險，因為在這些年來因為沒有盡早測試而產生的問題如下：

  • 測試人員可能沒有參與軟體的初始規劃，通常導致測試對系統了解有限+最後分配給測試的資源又嚴重不足
  • 許多需求，架構和設計缺陷都沒有再一開始被『發現』和『修復』，直到實作後而浪費了大量的精力修正
  • 隨著更多軟件的生成和集成，越到後期，修復和回歸測試變得更加困難（代價非常高昂）
  • 封裝使得執行白箱測試變得困難，並且在測試期間實現高水平的程式碼涵蓋率
  • 不足夠的測試與修復缺陷的時間，而延長了可以發行新版本的週期，這會產生『技術債』的波動，如果專案越大，越可能會使產品陷入一個困境中


使用 TDD 也不代表不需要 Modeling 分析

許多人都誤解了一件事情就是，直接學習 TDD 而跳過學習 Modeling 的分析像是 OOAD／UML 之類的，許多人以為不需要特別分析與設計物件就會自動跑出來，這其實是不太正確的，因為 TDD/BDD/SBE 少了強調建立 Domain Model 的這個步驟，認為反正找到的物件若不恰當，也可以透過重構不斷地來改變產品的品質。但是這其實會產生另一種技術債與浪費。

TDD 在開始撰寫測試時，也是要經由一個分析的過程找出 Use Case Model 並透過 modeling 分析或者您慣用的 UML 分析也可以，找出 Domain Model 後，才可確定 User 要的是什麼（價值／功能），許多人會覺得 OOAD 很難學，相較之下 TDD 容易上手多了，但是事實上，軟體開發這些工作並不會減少，沒有 Use Case Model 與 Domain Modeling 的分析過程，你所撰寫出來的 Production 只是可能在養大另一個技術債而已，你的軟體架構應該還是來自於使用者需求才是。

雖然（敏捷／TDD）都不鼓勵事前的大量分析，但是也不表示完全不分析啊。


軟體架構的敏捷？

有些讀者看到這裡可能會覺得，軟體架構跟敏捷有什麼關係？透過插件式軟件架構 Clean Architecture 便可說是完全為了這個問題最佳解決方案了，先前筆者的課程『跨平台的 Web API Framework 框架開發』便是在說明這件事情，下一次，筆者會將目前正在研究的使用 ASP.NET Blazor 來實作的 Easy Architecture 架構的實現， Easy Architecture 是我所開發的基於 Clean Architecture 架構的一個實現。


References：

https://insights.sei.cmu.edu/author/donald-firesmith/

https://insights.sei.cmu.edu/sei_blog/2015/03/four-types-of-shift-left-testing.html?fbclid=IwAR24flSk6qsS8OKuuHSl5NtfZS7_Mf5ZhynN5erkDN5jUMLk0b-O4QygS64

https://www.infoq.com/articles/quick-guide-atdd



關於 Gelis：

資深 .NET 技術顧問

FB 社團 (軟體開發之路)：

https://www.facebook.com/groups/361804473860062/

FB 粉絲團 (Gelis 的程式設計訓練營)：

https://www.facebook.com/gelis.dev.learning/

我講授過的課程 SlideShare：

https://www.slideshare.net/GelisWu


以下是我經營的項目與內容：

(1). 企業內訓課程

(2). 專業顧問


企業內訓課程：

1. .NET Core 3.1 從入門到進階

先前實體課程連結

2. 跨平台的 Web API Framework 框架設計

先前實體課程連結

3. 決戰 OOAD 系列課程 - 使用 UML

先前實體課程連結

4. 單元測試 UnitTest 與 Moq 物件實務課程

先前實體課程連結

5. 快速開發系列 - C# Project Templates 範本設計

留言

張貼留言

這個網誌中的熱門文章

軟體架構設計：API 設計準則（二）、API Design-First 原則、策略與開發流程

圖片
軟體架構設計：API 設計準則（二）、API Design-First 原則、策略與開發流程 圖片來源：https://coolshell.cn/articles/18024.html 前言 本篇文章是上一篇『 軟體架構設計：API 設計準則（一）、API 的設計開發與挑戰 』的接續。前一篇文章中，我們探討了 API 的開發與挑戰，這還沒結束，這篇我們來聊聊什麼是 API Design-First 優先設計？這與傳統的軟體開發有些不同，這與我們已經熟悉的 RESTful API 的以 Resource-Based 為設計的設計概念也有些不同，下面，我們就來探討吧！ 為什麼需要 API 設計原則？ 在說明為什麼需要 API 設計原則時，我得先回到一開始的主題 API Design-First 優先設計，為什麼需要 API Design-First 呢？因為 API 設計有別於傳統軟體開發，差異等等下方解釋，在設計 API 時講求有效的產出，首先是別企業體的或企業組織為維持市場競爭力與獲利所擁有的能力與模型稱為：【商業能力】，而在開發 API 時將將用戶與開發者視為第一考量，講求的是盡可能讓用戶在不牽涉過多技術細節便可調用這個 API。 在早期，許多企業未遵循 API Design-First 流程開發方法，而使用傳統方式設計 API，會後得到的結果可能就是『多次的砍掉重練及更冗長的開發週期』或最終 API 不為其他客戶所使用，甚至退出市場。 從 RESTful 到 API Design-First 優先設計   圖（一）、傳統 Resource-Based 的 RESTful API 原本我們熟知的 RESTful API 是將數位世界中的圖像、物件、後端的人員，都可稱為資源，這又稱作 Resource-Based API 的設計，因為 RESTful 將網路上的一切都視為資源。 但是在API Design-First 的概念裡面： 1. 資源 ≠ 資料模型 好的 API 設計提供的是該企業的數位能力，而不是後端的資料結構，因為 API 涉及的是跨企業之間的資料交換，這裡的 API 設計並不是傳統 SPA 應用程式裡面的 Front-end Framework 去呼叫的那個後端 API，這是兩個完全不同的開發情境，這必須先說明清楚。 另外優秀的
閱讀完整內容

常見的程式碼壞味道（Code Smell or Bad Smell）

圖片
常見的程式碼壞味道（Code Smell or Bad Smell） 圖片取自：https://www.slideshare.net/ElMahdiBenzekri/art-of-refactoring-code-smells-and-microservices-antipatterns 前言 究竟重複的程式碼要不要共用它？傳統的軟體開發上，重複的程式碼幾乎被視為罪惡的來源，但是它真的有多可怕？ 常見的 Code Smells The Dispensable （一些可有可無的） Lazy Class (冗員類別） 如果一個類很少使用它會增加代碼庫的複雜性，從而阻礙開發。這樣的類可能是不必要的，它的功能可以成為另一個類的一部分。 Data Class (只有資料的類別） 一個類別只有包含『資料』未包含Methods，也就是說並未包含行為，不具行為模式的類別代表該『實例』容易被【其他類別所操控】。 Duplicate Code (重複的程式碼) 如描述，這也是上次有分享在我的 FB 社團 軟體開發之路［德國資深架構師給新手的建議］ 中有產生非常熱烈討論，這在社團朋友提醒下想起 Refactor 重構一書裡曾提過 rule of three 法則， 這個法則的定義是這樣的，有時部分程式碼重複其實是允許的（不是說重複一定是是被允許的）而是在某些 Context 情境下，該程式碼有一段時間不會衍伸別的功能 或 需求一段時間不會異動、且如要將它 DRY 會產生的『複雜度』或『花費時間』遠高於預估的時間 或 不值得在目前這個專案的節骨眼上花費這個時間來做這件事，加上它 DRY 產生的複雜度偶後產生的維護成本【遠高於】不 DRY 的情況下的維護本，那麼，在這個時候，這個異動頻率【極低】的程式碼就不需要花費這個時間來 DRY 了！！ 因為重點在於，重構是需要『成本』的。(迷之音：DRY 是種抽象化阿~😎) 這讓我想起之前，大約在 2016 年左右，在 101 的樓上某金融業客戶，曾經做過一個專案，這個專案就是因為客戶 DMZ 環境的因素，我讓內網的 Webside 與 DMZ 的網站保留了部分重複的程式碼，因為這段程式碼終年不需要異動，我也懶得花這個時間，而我居然也忘了這記件事情了.. 哈哈 Orz 不過原歸正傳，我個人還是認為，其實適當
閱讀完整內容

什麼是 gRPC ？

圖片
圖片取自： 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 也完全的跨平台。要在 .
閱讀完整內容