AI 時代的軟體架構設計的進化之路（二）

AI 時代的軟體架構設計的進化之路（二）

在彎道加速前進的 AI 跑車

文章目錄

前言

在前一篇文章 【AI 時代的軟體架構設計的進化之路（一）】中，我們探討了 AI 對軟體架構設計的影響，當時，我解釋了軟體在時做過程中，系統分析與設計的過程是幫助我們工程師思考的一個重要過程，因為這個過程才能夠幫助我們客戶的需求合理或不合理之處、理解最佳的系統設計的 boundary 那個界線在哪裡？如何將目前的『需求』實作到最佳恰到好處？


AI 對軟體架構設計的影響

現階段的 AI 或 GAI 工具嚴格來說，都還僅限於副駕駛 Copilot 的角色，但是軟體在設計的過程中得執行許多決策，且軟體開發的過程中並不是只有撰寫程式，更多的是『溝通』、『協作』、『解決問題』，單純的撰寫程式可能只占整體軟體開發生命週期所有大小事情中不到 20% 的工作量，當然也還包刮了測試、部署、維運等工作。然而，大部分的工作均需要開發人員進行『思考』與規劃，但是規劃這件事情需要考量的不單就只是如何實作，可能也包括了『團隊成員Skills』、『客戶端執行環境』、『成本的限制與考量』、甚至是『如何與其他進行跨系統整合』、等...，而這些都是還是需要人來進行決策，與如何進行下一步的。


如何讓 AI 來遵循 UML 軟體設計方法論 Methodology 的設計規則

大約在 2025-08-15 左右，我開了一堂【AI 時代下的系統分析與設計】線上直播課程，課程大致上其實先前我的決戰 OOAD 系列課程 與 最新的 API Framework 框架開發V2 課程的延伸，雖然我會在課程中使用 AI 工具 GitHub Copiplot，但重點仍就放在軟體建構過程中的各個環節點，比如從需求訪談到需求的擷取、也就是系統分析/設計）的過程，只不過，我讓 AI 來介入系統分析與設計的過程的環節點，而不只是與 AI 來 Pair-Programming 而已，我這樣做的目的是希望幫助軟體開發者不要停止思考，我記得，最近有看見 Continuous Delivery 一書的作者 David Farley 似乎也提到說 Vibe Coding 是本年度最糟糕的主意，David Farle 他提到 AI 可以加快開發速度，但同樣毫無疑問的，Vibe Coding 可能會讓開發人員減少對程式碼的『思考』。而這件事情長期來看是危險的。怎麼說呢？因為使用 AI 工具時，慢慢的花最多時間的不是在思考如何開發，反而是在「等待」AI 回應我下的提示詞，這種等待短則 1-2 分鐘，長則超過 5 分鐘以上。然而你會想說，我一開始一定會仔細的審核校對 AI 替我撰寫的程式碼，但時間一久，如果專案時間在趕、而 AI 撰寫的程式也都能夠 Compile 、且運行也無太大問題，慢慢你會想說，算了，不仔細 Review 應該也沒什麼關係吧！？... 而就是這件事情，長期看起來是危險的。

就在 David Farle 提到這個論點之前，我自己近 1 年多，在接觸 AI 與 AI 協同開時的感想與體會與 David Farle 是完全一致的，於是我才有這樣的課程出現，目的就是希望開發者在進行軟體設計與開發時，AI 工具要用，但是也不該停止思考，我們可以藉由 AI 相關的工具來加速開發的過程、與降低花費成本，並藉由 AI 介入我們系統分析/設計）的細節，因為軟體開發中，因為使用的 Methodology 會讓軟體開發的過程有一定的可控性。

而讓 AI 介入軟體開發的過程讓我們在實際的軟體開發過程中獲得以下好處：

  1. 這麼做，除了軟體設計過程的產出亦可以保存下來外
  2. 我們透過 AI 簡化 與 加速了這個（分析與設計的過程）
  3. 當 AI 有個 Methodology 可以依循時，設計起來結果都能預期了!! AI 不會再有幻覺了，結果的正確性也提高了
  4. 因為分析以及設計與實作的過程的產出都會保存下來、這表示專案累積的經驗都會被保存下來

把 Scenario 轉換為 prompt （精華篇）

圖（一）、使用描述 Use Case 的模型語言來描述需求 使用描述 Use Case 的模型語言來描述需求

在本次課程中，我以一個線上的車輛租用系統為例，示範怎麼在 Use Case Modeling 界定 boundary 後，如何將 Scenario 專換為 UML 描述語言，並說明給 GitHub Coiplot 的 GPT 4.1 來產生固定的 Use Case Modeling （註：更多時候，我更喜歡用 Use Case Modeling 來取代 Use Case Diagram 的解釋，因為，對我來說 Use Case 不光是一張圖，更是一個模型）

圖（二）、藉由方法論來約束 AI 進行系統設計的方向 Copilot 要產生 Methods 也都是有跡可循

然後，再以 PlantUML Script 來產生 Sequence Diagram，然而我覺得更棒的是，UML 在各項圖形的轉換是有規則的，這在當你透過 PlantUML Script 來描述時更能夠體會這個好處，因為 LLMs 理解程式語言=PlantUML Script 速度遠超過人類，所以這裡也可以說我們使用 PlantUML 來約束系統的設計方向。如範例中，我們在 Sequence Diagram 中及告知 GPT 4.1 我們得在 RentalService 這個領域物件裡提供 [toRentalCar()] 這個方法，而 AI 也是完全看的懂這個規則，GPT 4.1 產生的 Class Diagram 也都完全的符合我的預期，這就是我剛剛說的【藉由特定方法論來約束 GAI 不至於產生過多幻覺】。

更多的說明，歡迎報名最新的【AI 時代下的系統分析與設計的 7 堂課（第二堂）】

購課連結： 

https://mystudyway.kktix.cc/events/analysis-for-ai-2


結論

以上開發，均是最近使用 AI 改善軟體開發與流程時，實際進行的項目，我們進行開發的結果也都還不差，在藉由 Copilot 自動 Commit 與撰寫 Message 的描述也都還算精準。整個開發下來，開發人員仍然需要思考，因為每一個過程雖然 AI 介入，但是開發人員仍然需要搞清楚需求的實際與要實作的內容是什麼？而且，過程也真的都變快了，因為開發人員並不需要自己繪圖，只要核對 GPT 產生的圖形是否正確，當然了，你的 Scenario 如果一開始就沒有確認，那麼 AI 也幫不了你了。

待續...

留言

張貼留言

這個網誌中的熱門文章

占空間的Google Chrome暫存檔

圖片
在一次使用CCleaner清除系統的垃圾的時候發現，怎麼Google Chrome怎麼有220M的網際網路快取資料？ 這時突然意會到，平時都只記得清除IE的Temporary Internet Files，卻忘了Google Chrome也是瀏覽器，一樣會產生暫存檔案，還有Google Earth產生的暫存檔居然更高達688M… Orz 因此突然間也非常好奇這些暫存的資料夾的路徑到底在哪裡呢？因為我們知道在Windows Vista/7 之後使用者資料已改在c:\Users 的下面，由於IE的是在"C:\Users\gelis\AppData\Local\Microsoft\Windows\Temporary Internet Files" 、所以我想應該也在這裡附近。果然讓我找到了！ Google Chrome : C:\Users\gelis\AppData\Local\Google\Chrome\User Data\Default\Cache Google Earth : C:\Users\gelis\AppData\Local\Google\GoogleEarth\models 可是突然間又發現Google Earth的資料夾居然是空的！這讓我很疑惑，明明掃出688M，究竟這些檔案是在哪裡呢？筆者的求知慾又非常強烈，每當發現問題如果不找出來是不罷休！因此常常熬夜只是為了找一個問題… 後來上Google才發現，原來我找錯位置，Google Earth的暫存資料是存在LocalLow的下面！不是Local的下面，所以路徑應該是如下： C:\Users\gelis\AppData\LocalLow\Google\GoogleEarth 而且是單一檔案"dbCache.dat"，總算解了疑惑 ^_^
閱讀完整內容

什麼是 gRPC（二）- 來撰寫第一個 Hello World 吧！

圖片
前言 上一篇 什麼是 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...
閱讀完整內容

常見的程式碼壞味道（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 不過原歸正傳，我個人還是認為，其實適當...
閱讀完整內容