我是稱職的顧問嗎?

來集英已經快兩年，但...究竟我是不是稱職的顧問?

from gelis 技術隨筆- 點部落 http://ift.tt/1PUNsF6

留言

張貼留言

這個網誌中的熱門文章

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

圖片
AI 時代的軟體架構設計的進化之路（二） 文章目錄 前言 AI 對軟體架構設計的影響 如何讓 AI 來遵循 UML 軟體設計方法論 Methodology 的設計規則 把 Scenario 轉換為 prompt (精華篇) 結語 前言 在前一篇文章 【 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 是本年...
閱讀完整內容

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

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

圖片
目錄 前言 當程式都是 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，撰寫一套五子棋小遊戲是出乎意料的快， 然而，你必須知道，此需求屬於不複雜（雖然本身具備演算法、但大家對於五子棋的理解大致上一致） + 所以可算需求精確 + 網路上的現有程式碼邏輯清楚 + 線上現有資源豐富，所以當然撰寫速度自然飛快， 但是，在封閉的企業端，軟體設計大都來自商業與市場需求，需求來源大都都為『口述』、某些實際使用者（人類）的想法 ，加上，執行還多為企業端自...
閱讀完整內容