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


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

目錄

  1. 前言
  2. 當程式都是 AI 撰寫的、軟體架構設計還重要嗎？
  3. 到底什麼是軟體架構設計？
  4. 所謂的『變』與『不變』的部分
  5. 軟體技術架構的本質
  6. AI 時代的軟體架構師的角色與定位
  7. 結語

前言：

現在 AI/GAI 各式工具如雨後春筍般湧現，現在早上一起床，腦子便想著 AI 世界又有什麼新的新聞/變革？又有什麼新的 GAI 工具誕生？哪一個工作要被取代了？開發人員又有什麼新的東西要學習？現在的開發人員的壓力真的很大，AI 對世界產生的衝擊，似乎軟體開發人員最首當其衝的感覺！？甚至我的岳父，上個月有一次來家裡玩，看到我都順口問我：對了，最近那個 AI 的出現，對你們的工作有沒有影響啊？？.. 這我..哈哈，我的岳父其實對這領域是個大外行，連他老人家都聽聞此訊息與消息，證明 AI 席捲世界並非空穴來風、各行各業都受衝擊、與影響，影響程度多寡、有些只是現在進行式、有些還在觀望，有些還在堅持著硬撐著、看似沒什麼改變，日常仍舊是日常、生活還是要過，話雖如此，了解 AI 的發展趨勢，與 AI 對軟體開發的影響，對於各行各業、甚至對我們軟體開發者來說，這是個終究必須要面對的重要課題。

當程式都是 AI 撰寫的，軟體架構還重要嗎？

最近市場常常會拋出一些問題出來，像是：軟體工程師終將被取代、〔資訊科系不再吃香，該系畢業生何去何從？〕、〔寫程式的門檻大幅降低，麻瓜都可以寫扣！〕

圖（一）、使用 Claude 撰寫的線上五子棋小遊戲 使用 Claude 撰寫的線上五子棋小遊戲

最近，曾經撰寫程式碼不假於它手的我，漸漸地開始使用 Cursor 或是 GitHub Copilot 之類的 GAI 工具來幫助我撰寫程式碼，我也發現就算我程式撰寫的再快，也快不過 AI，尤其是 LLM 的模型像是先前 Codex 或是增強的 GPT-4、4o、o4-mini 或 Claude Sonnet 3.7/4.0 系列的 Anthropic，撰寫一套五子棋小遊戲是出乎意料的快，然而，你必須知道，此需求屬於不複雜（雖然本身具備演算法、但大家對於五子棋的理解大致上一致） + 所以可算需求精確 + 網路上的現有程式碼邏輯清楚 + 線上現有資源豐富，所以當然撰寫速度自然飛快，但是，在封閉的企業端，軟體設計大都來自商業與市場需求，需求來源大都都為『口述』、某些實際使用者（人類）的想法，加上，執行還多為企業端自己建置的伺服器 + 軟體運作環境，因此 RAG 因應而生，成為當紅的炸子雞，但我們要思考的是，現在 GAI 產生的內容仍舊存在不確定性，因為 LLM 採用的為預測下一個機率最高的回答，雖然 RAG 讓我們企業內部系統與其整合的時間與成本以及『門檻』大幅降低，但人應該才是最後的決策者，軟體架構也是。

什麼是，軟體架構設計？

圖（二）、什麼是軟體架構設計 什麼是軟體架構設計

這個主題，我應該已經談論非常多次了！哈哈，就像上一次我在成功大學對學生分享的軟體架構設計一樣，在設計系統的過程中，你會做許多的『決策』，這個決策的來源也許是某些使用者需求的萃取物（精煉的結果）、或者是一段重構的想法、或甚至是一個套件的升級或安裝，而這個『決策』你必須根據當下情況，套件升級的 Effort？團隊成員能否具備新版的 Skills？程式碼重構、異動後產生的影響？需求變更的 Scope 範圍是多少，然而這裡的後者的決策又可能遠遠的影響著前者的程式碼修改的範圍，這範圍也影響著可能改壞哪一些系統的可能性，這些才是我談論的軟架構設計中的決策部分。

『變』與『不變』的部分

現在，許多自動化、重複性工作慢慢會交給 AI 來完成，AI 甚至可以幫忙撰寫 Unit Test 與產生特定程式碼，透過 ONNX Runtime 或是 Semantic Kernal 與企業內部現有程式碼整合，透過 Description 等（需求/Prompt）產生明確的的 Method 的程式碼，但是要注意的是 AI 可能仍有錯誤，因為 AI 不見得知道專案從 Kick-Off 開始的來龍去脈、與顧客的所有會議的決議、口頭上的說明等等，這些 AI 可能並不清楚，所以 AI 只能算是片面的解決眼前的問題，實際的決策者可能還是架構工程師，工程師的職缺並不會真的消失，這是不變的部分。所以，人還是得跟著 AI 一起學習與成長，GAI 完成應該被自動化、與機器本來就擅長，但是人來做很耗費力氣的事情，像是我先前的 Bootstrap 5.2.3 的升級，因為由 3.X 升上來，許多 class/style 語法上的改變、甚至 grid system 改為 flexbox 的寫法，這些樣式的變化，如果人工核對來修改套耗時了，這次我請 GitHub Copilot 來修改大約只花費幾分鐘，就將一個網站10幾個頁面修改完畢，這若是由工程師來進行，即便用 Replace 方式進行，人工核對難免出錯，而且耗時耗力，這效率真的能差上 10-100 倍以上。

軟體技術架構的本質

圖（三）、軟體架構設計的本質 軟體架構設計的本質

在回到軟體架構的本質，這又可以再拿起先前我繪製的〔什麼是軟體架構設計〕這張草圖，描繪了真正的軟體架構設計除了要先釐清內外領域要解決的問題外，其它的都是溝通的問題。著名的 Clean Architecture 一書的作者 Uncle Bob 就已經告訴我們『軟體架構的目標是最小化建置和維護『需求系統』所需要的人力資源』，所以.. 軟體架構設計在設計什麼？其實也是在設計一個【可以讓企業賺錢的系統】，也像康威定律裡面所講的，軟體架構不關與你的（客戶需求/期望）息息相關，它與你的企業組織架構相關外，也與協作有著非常密切的關係。圖中的目標要表達的是一個核心領域要解決的問題目標與價值，也就是你要專注解決的核心領域需求，這裡也使用了 DDD 的 Core Domain 的概念。軟體架構要作好，那不是一個人的事情，你要解決的是對內、甚至對外的領域問題。

軟體架構不是你自己作爽的，是許多的認知、共識下、環境的產物，甚至最後可能是妥協出來的，它不見得是你當下現在看得上眼，以及對其它團隊或領域來講不是個多好的架構或方式。但卻可能是你們目前 Context 下，最適當的架構。

所以，軟體架構設計的本質還是在【人】身上。

AI 時代的軟體架構師的角色與定位

最近，我現在閒暇之餘，也在研究 AI 對於系統分析的助益、同時間，在對新系統進行軟體架構的初步設計時，也嘗試、想了解 AI 對於繪製 UML 相關圖形時產生的幫助，因為『使用者需求』也是得由『人』去談 + 消化 + 吸收、接著產生 Prompt，然後藉由相關圖形 GAI 來產生 UML 相關圖形。

在搜尋資料的研究過程中也發現，訪間目前已經有些工具做得不錯： 

(1). Miro 

(2). DiagrammingAI

上面這兩種工具是可以實現輸入 Prompt 直接產出 UML 圖形的功能服務，根據下方的餐搞資料的敘述，可這一來，可多人協作共編 UML，更進一步將敏捷開發、DevOps 應用在 UML 製圖，藉由團隊成員集思廣益，建立更完整的軟體開發藍圖和流程。

後來，據說有研究團隊發現可以利用開源 UML 工具「PlantUML」來繪製 UML 圖形，該團隊先在 ChatGPT 用一段 Prompt 開立需求，轉譯為 PlantUML 的格式和指令，這部分我也嘗試過，我試著將 User Scenario 轉為 Prompt 並餵 Copilot 以產生 PlantUML 的命令。

圖（四）、使用 PlantUML 產生的 Use Case Diagram 使用 PlantUML 產生的 Use Case Diagram

接著，我只要按下 Alt+D 就會動態繪製這個 Sequence Diagram，我在 Prompt 表明我要繪製租車系統的 Sequence Diagram，如下圖（五）

圖（五）、使用 PlantUML 產生的 Sequence Diagram 使用 PlantUML 產生的 Sequence Diagram

另外，我也常是一些地端的 SLM 模型、像是 Phi-3 的 mini-4k 等，嘗試在程式碼將(使用者需求/Prompt) 轉為 PlantUML 命令，這樣就有機會以自動化的方式在 WK 系統中，由需求單的填寫單位，自動化產生 UML 相關圖形、甚至自動化產生程式碼。

圖（六）、OnnxRuntime Phi-3_mini_4k 模型產生 PlantUML 測試 OnnxRuntime Phi-3_mini_4k 模型產生 PlantUML 測試

只是，又回到我以前提到的一個問題，我舉個例子好了，就是：我們在進行 Use Case 的系統分析時，這時的系統分析的重點是在於，這個 Methodology 在分析過程中幫助你釐清了哪一個物件是在『主要事件流的外層、而不是在這個 boundary 裡需要被關心的』，這才是 UML 的 Use Case 圖形分析的重點之一。你將使用者需求、或是 User Scenario 轉為 Prompt 這部分可能仍然需要『人』的介入，而轉換成圖形的部分，自動化是沒有問題，但圖形仍然有可能不正確。因此，我也試著反過來，讓 ChatGPT 來讀取我的 Use Case Diagram 如下圖。

圖（七）、ChatGPT 讀取 Use Case Diagram ChatGPT 讀取 Use Case Diagram

在反轉回 PlantUML 命令，那麼往下產生 Sequence Diagram 也就比較不會失真太多。這段，我可以呼叫 OpenAI 的 API 來完成，這樣就可以將 Use Case Diagram 轉為 PlantUML 的動作自動化來完成。

另外，AI 還是無法解決許多需要決策的問題，我再舉個例子：因為 AI 產生的圖不見得正確，我想討論的是，在 UML 的系統分析與設計的過程中，往往因為這個 Methodology 的運用幫助我們思考，而在繪圖的過程中釐清 Users 的需求，因此用視覺化工具來繪製 UML 我認為會比使用 PlantUML 這類語法回繪製 UML 來的精確，當你轉為 Prompt .. 當圖形有誤，那你得在藉由 Prompt 來修復或微調圖形，告訴 GAI 比如：你發現這個 Use Case 不再這個主要事件流內，請移除，並新增另外一張 Use Case Diagram。但是【你自己要發現、知道，知曉、與了解這個需求的問題點】，AI 是幫不了你的，你還是得自己做分析才會察覺問題點在哪裡，然後這個 Prompt 才會下的正確。

結語

AI 時代的軟體架構師的角色是否還會存在，我的答案是永遠會存在，只是需要的知識只會增加而不會減少，架構日益複雜、工具提供的資訊需要系統領域知識、環境、架構、甚至市場了解兼具的決策者，方能決斷下一步該怎麼走，對於軟體架構師而言，需要的知識量只會不斷的增加，AI 終究只是輔助工具，幫助我們更快、更精確地完成軟體架構設計的工作。AI 可以自動化許多工作的重複性、繁瑣的工作，讓人專注在【客戶實際的商業需求】上面，但最後該要怎麼做？最終的決策仍然需要人來做出，前面我也提到了，軟體架構設計的本質在於人與人之間的溝通、協作，以及對系統需求的深刻理解，許多事情 AI 是幫不了你，你還是得控制與確保軟體的發展方向是如你所預期的方向，方向應該由人來決定，不是 AI。


References:

FIND科技報:利用AI繪製UML流程圖 及早站穩軟體開發和運作流程的馬步

https://paper.udn.com/udnpaper/POH0046/401294/web/

Creating UML Diagrams with ChatGPT +AI

https://www.youtube.com/watch?v=buET5brQHFQ


留言

張貼留言

這個網誌中的熱門文章

什麼是 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...
閱讀完整內容

什麼是 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 也完全的跨平台。要在 ....
閱讀完整內容