您的軟體架構夠敏捷嗎?

圖片來源: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 範本設計

留言

這個網誌中的熱門文章

什麼是 gRPC ?

軟體架構設計:API 設計準則(二)、API Design-First 原則、策略與開發流程

什麼是 gRPC(二)- 來撰寫第一個 Hello World 吧!