Gelis 技術隨筆-部落格

目錄 前言 當程式都是 AI 撰寫的、軟體架構設計還重要嗎？ 到底什麼是軟體架構設計？ 所謂在軟體開發中『變』與『不變』的部分 軟體技術架構的本質 AI 時代的軟體架構師的角色與定位 結語 前言： 現在 AI/GAI 各式工具如雨後春筍般湧現，現在早上一起床，腦子便想著 AI 世界又有什麼新的新聞/變革？又有什麼新的 GAI 工具誕生？哪一個工作要被取代了？開發人員又有什麼新的東西要學習？現在的開發人員的壓力真的很大，AI 對世界產生的衝擊，似乎軟體開發人員最首當其衝的感覺！？甚至我的岳父，上個月有一次來家裡玩，看到我都順口問我：對了，最近那個 AI 的出現，對你們的工作有沒有影響啊？？.. 這我..哈哈，我的岳父其實對這領域是個大外行，連他老人家都聽聞此訊息與消息，證明 AI 席捲世界並非空穴來風、各行各業都受衝擊、與影響，影響程度多寡、有些只是現在進行式、有些還在觀望，有些還在堅持著硬撐著、看似沒什麼改變，日常仍舊是日常、生活還是要過，話雖如此，了解 AI 的發展趨勢，與 AI 對軟體開發的影響，對於各行各業、甚至對我們軟體開發者來說，這是個終究必須要面對的重要課題。 當程式都是 AI 撰寫的，軟體架構還重要嗎？ 最近市場常常會拋出一些問題出來，像是：軟體工程師終將被取代、〔資訊科系不再吃香，該系畢業生何去何從？〕、〔寫程式的門檻大幅降低，麻瓜都可以寫扣！〕 圖（一）、使用 Claude 撰寫的線上五子棋小遊戲 最近，曾經撰寫程式碼不假於它手的我，漸漸地開始使用 Cursor 或是 GitHub Copilot 之類的 GAI 工具來幫助我撰寫程式碼，我也發現就算我程式撰寫的再快，也快不過 AI，尤其是 LLM 的模型像是先前 Codex 或是增強的 GPT-4、4o、o4-mini 或 Claude Sonnet 3.7/4.0 系列的 Anthropic，撰寫一套五子棋小遊戲是出乎意料的快， 然而，你必須知道，此需求屬於不複雜（雖然本身具備演算法、但大家對於五子棋的理解大致上一致） + 所以可算需求精確 + 網路上的現有程式碼邏輯清楚 + 線上現有資源豐富，所以當然撰寫速度自然飛快， 但是，在封閉的企業端，軟體設計大都來自商業與市場需求，需求來源大都都為『口述』、某些實際使用者（人類）的想法 ，加上，執行還多為企業端自...

軟體架構設計：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，這是兩個完全不同的開發情境，這必須先說明清楚。 另...

雜談：軟體設計中 Cross-Cutting Concerns 的重要性 圖（一）、Cross-Cutting Concerns 跨領域關注點 前言 什麼是 Cross-Cutting Concerns 跨領域關注點？我比較少專注談論這個主題，事實上，這不是什麼很新的技巧，也不是什麼狠了不起的高端技術，只不過，我認為有些設計技巧是這樣，看似不難，不過要真的能在專案、實務上的軟體架構中均衡的實踐，那就有一定的難度。 實踐部分，常見的手法即是 AOP, Aspect Oriented Programming 後面都簡稱 AOP，而這個技巧在 .NET C# 上就有多種實踐手法，這個早在 2014 年時，我替竹科某廠所設計的 Web API Framework (net451) 的框架裡，就充分利用這個技巧來將系統服務，像是 Logger (紀錄)、Exception Handlers (例外處裡機制)、Notification/SMS (通知) 等等的實作 與 商業邏輯分開。實作方法我們稍後來說明。 什麼是 Cross-Cutting Concerns 跨領域關注點 這其實是軟體開發上，一直存在的普遍問題，這問題在傳統階層式架構上也存在，我發現訪間有些文章扯進了 Clean Architecture 整潔架構，事實上不管你使用哪一種架構， 這類跨越不同層的程式碼卻還是得因為某些 None-function 的需求，得相依某些底層服務的問題，其實一直存在 。 通常在設計系統時，關注點分離，讓我在實際進行開發時，只需要專注在某一個模組/Layers 而不需分散注意力在其他的模組或者不同層次的位置上，且開發完成，不需考量各層彼此如何介接，因為每一層早已經定義好彼此互通所使用的協定與溝通的方法，像是 MVC 即是類似的框架。 回到跨領域關注，在軟體的開發上，尤其在企業商業邏輯的開發上面，在程式碼的實作上，我們知道程式碼當然是越簡單、行數越少越好，再說 SRP 也告訴我們一個元件、一個 Method 最好只有一種被修改的理由越好維護，只不過實際的程式碼。為了寫 Logger，為了實作驗證等，往往一定會與底層相關套件或模組相依，總還是會有部分程式碼讓這一個被修改的理由中，相依著其他外部組件、套件，這些在 Clean Architecture 裡，應該屬於 Infr...

軟體架構設計原則：導論 我說明一下，為什麼會有這篇文章？因為最近，我正在籌備一個全新的課程，這門課算是我多年來在企業端顧問 + 也包括帶團隊做專案，也包含了幾次替企業客製化 API Framework 框架的相關實作經驗的體現。 記得，好幾年前我分享過一堂關於【 您的軟體架構構敏捷嗎？ 】的課程，這堂課程其實就是在告訴你，實務上進行開發時，沒有什麼開發的需求得要完全的想清楚、完全得清楚該怎麼做 + 或者是得完全的分析清楚後，才能進行程式碼的開發與撰寫。在敏捷的環境裡面，你沒有一項任務是進行所謂的軟體架構設計，但是你卻還是得進行當下適當的架構設計，這其實還蠻抽象的，但是你不應該在這個抽象預想、或者設計太多未來不太會用到、或者是根本不會用到的抽象設計在裡面，因為太多的設計一部分也又回到瀑布式的時代，難道你得全部分析完，才能開始寫程式？ 但.. 最近我也有篇文章【 為什麼我說在撰寫程式之前，還是先做個簡單的分析比較好？ 】說明，撰寫程式之前，還是先做個簡單的分析比較好？所以，那到底，我一開始要分析，還是不分析呢？答案是：你要做基本的抽象分析，但是只是做應該做的部分，什麼是目前應該做的部分？這其實需要蠻多相關的經驗，也沒有實際的標準答案，方早在與蔡煥麟老師互動時【FB 連結： https://www.facebook.com/share/p/PdntjirACrAvVhmw/ 】，我腦袋也迸出許多這些年來的設計與經驗感想出來 XD 圖（一）、DDD 戰術建模 - 建置 API 服務 通常，我們在進行系統開發時，會進行部分抽象的設計，在敏捷裡，我們可能會以價值為最優先考量來進行設計，但這個設計裡面，我非常喜歡 DDD 的 Core Domain 的概念，我不講過多的技術、也不希望有過多的平台設計或者框架的影子在裡面，我只希望先 Focus 在這個領域 (Domain) 裡面就好，因此，在藉由 Clean Architecture 的 Plug-In 的架構裡，我就可以先避免掉其他無用的抽象設計，也因此可以幾乎避免掉爾後的疊床架屋的設計出現。 圖（二）、先前小弟一堂課【利用物件導向五大設計原則 S.O.L.I.D. 來建立強固的軟體系統】的部分截圖 在不久前，約今年初，我也在企業授一堂課，關於透過 SOLID 建構六角架構的課程，這一堂課的主要內容其實也不是在...

從 Semantic Kernel 談 AI 浪潮下的開發人員的挑戰 圖片來源：https://blockcast.it/2023/03/22/will-chatgpt-replace-blockhcain-developers/ 前言 近年來，從前年 2022年11月30號 ChatGPT 推出以來，可說席捲整個世界，生成式 AI 將取代你的工作一詞不斷的在新聞媒體版面、各行各業、甚至你生活周遭出現，不亞於當年 iPhone 的推出，但我覺得更甚於此，因為 AIGC 的出現，讓我原先不看好的 LLM 大型語言模型原來能夠 Pre-Trained 到這樣的地步，類神經網路居然能將自然語言（NLP）的處裡，表達做到基本邏輯推演甚至通過圖靈測試的地步，這讓許多人、各行各業、開發人員都燃起盞明燈。而取代之說，也如雨後春筍般地湧現，是好是壞大家不僅開始思考各種因應的對策與方法。但趨勢通常都不可檔，只能去理解它、瞭解它、利用它、接受它、擁抱它、未來它會成為我們生活周遭的一部份。 在 AI 浪潮下，開發人員面對的是什麼？ 最近我一直在思考一個問題，在生成式 AI 的浪潮下，這對開發人員有什麼影響？我個人的看法是，開發人員未來要生存只會越來越難，我們得先做好充足的準備，但凡事總是有一體兩面，因為生成式 AI 有可能會使的基本的工具與技能不再重要？像是比較細微的工作，也就是粒度比較小的工作，像是翻譯這一段文字、為這個 Method 撰寫測試等等，以及一些需求明確，能夠以自然語言完整表達的（內容/Code）產生的工作可能都可以由生成式 AI 來完成即可。 但前面提到凡事都是一體兩面的，目前的 AI 以上下文來預測下一個字詞，這目前仍然可能有幻覺，也就是開發人員還是得做最後生成的內容的把關的動作，只是善用 AI 是能夠大大增加生產力，而開發人員可以更完全專注在（商業需求/業務需求 or 藥物目標）上。 對軟體產業的影響 當工具與技能不再重要？？其實這句話這樣說，其實也不太對，以前我們常說，替客戶開發專案使用的程式語言或是技術不重要，重要的是要能夠完全的達成客戶的期望。 因為，在人工智慧開始蓬勃發展的現代，如果 AI 能夠完成你的軟體架構的基礎樣貌，可能是 Class/Design Patterns 屬於客戶端自然語言生成的部分，也許有 50%-60% 我們可以不用關心...

為什麼我說在撰寫程式之前，還是先做個簡單的分析比較好？ 我們可以從討論中獲得共識，但你跟你的需求獲得共識了嗎？ 前言 上個禮拜，我在公司對新人進行教育訓練，我依舊按照我原來進行訓練的步驟開始，先了解主題與內容，也就是新人想學習得內容？比如是前端？或者是後端的開發等等。接著是新人的程度到哪裡？如果假設我是要教 C# 與 ASP.NET Core MVC 的開發，那麼我得先調查新朋友是否已經撰寫過 C# 以及對 OO (Object Oriented) 了解的程度到哪裡？再來，就是從我們一般進行專案開時，所所有會使用到的技術來排定學習的優先順序，當然了，也考量學習的新朋友目前所擔任的角色。 學習是需要被客製化的 再回到本文想要講述的重點，因為每一個人的基礎都不同，已經熟悉的技術內容都不同，所以經過客製化的訓練內容也會有些不同。 而我們現在談的是軟體專案開發，既然是專案開發，那麼開發的內容(產出的內容程式碼)是來自於使用者需求，所使用的技術只不過是幫助我們去勾勒出『使用者』需要的『成品』（也就是成運作+並達成使用者標的與期望解決的問題）的軟體最終成果（也許是網站 Web／APP／..Others）， 也就是說，使用何種技術只不過是種手段，但是你有沒有 Catch 到使用者真正的期望與需求那可能是另外一件事情。 在真的開始寫程式之前，建議還是做個簡單的分析吧！ 在開始之前，我隨口問了一下新朋友，你知道 OOAD 嗎？就是也可以拆解開來分別談 OOA/OOD ？ 結果新朋友告訴我，她只有聽過 OOP 而已，沒有聽過 OOA 與 OOD? 我聽到之後非常的驚訝，因為這位新朋友再來公司之前去恆逸上過課而已，也許已程式開發為主的課程並不會提及這些，也有可能軟體開發內容層面範圍較廣無法全面提及也是實屬正常。 我告訴她，其實在台灣目前的產業裡，也不太重視分析／設計這兩個階段，但是我個人反而比較重視這想個階段，但並不是說我不重視使用的技術 & 軟體架構設計，因為使用哪一種軟體架構設計／Patterns 是來自你的『使用者需求』，像是幾年前，我曾經寫過一篇文章：『 從使用者需求、談軟體架構設計 』這篇文章所講述的內容一樣，一切都是來自你的需求。 而有部分 Bug 亦是從需求而來，而從需求而來的 Bug 往往最難修改，可能得翻掉架構也說不定。 圖（一）、從需...