.NET Walker

上禮拜在改 Azure DevOps 的 Pipeline，因為客戶遇到一個很實際的問題。 用戶抱怨，每次 Pipeline 跑完，他們團隊的 PM 和相關人等都跑來問：「這次測試過了幾個？Coverage 多少？部署有沒有成功？Sonar 掃描的報表結果如何?」 苦主耐心地一一回答：「這些資訊都在 Pipeline 的 tasks 裡面啊，你們自己點進去看就好。」 但是，這些大爺們從來不想自己去一個一個 tasks 去點，他們希望有個「一目了然」的整合頁面，能直接看到他們想要的重點數字就好。 『就算我說服了他們，他們也真的自己去看，但沒多久又在 LINE 上問我：那個 Log 到底是什麼意思？這個掃描報告要在哪裡找?』 就這樣『來來回回，他們累了，我也累了。』 苦主無奈地說。 需求很簡單：給我一個摘要頁面就好 大爺們最後跟苦主說：「你能不能幫我們在 pipeline 裡面弄一個 Summary 頁面？我們只要打開就能看到重點數字，不用再去翻那些 log?」 恩恩，我被問到的就是這個… Pipeline 跑完之後，能不能有個漂亮的摘要頁面，一進來就看到重點： 測試通過幾個、失敗幾個、Coverage 趨勢 部署到哪個環境、- 有沒有什麼重要的警告 源碼掃描報告的摘要是如何? 自動化測試結果? 能不能上正式機? … 就這樣。 說的很簡單，要蒐集到需要的資訊似乎也還算容易。 但問題是，要怎麼把這些資訊「塞」進 Azure DevOps 的 Pipeline Summary 頁面？ 然後我發現了個神奇的東西 在翻 Azure DevOps 的文件時，我發現一個很有趣的機制。 你知道那些客製化的 Extensions 是怎麼樣讓你在 Pipeline 的 Summary 頁面看到額外的資訊(例如掃描報告、測試報告)的嗎? 類似底下這樣： 答案可能會讓你傻眼，不是呼叫什麼 REST API、不用設定什麼 Token、也不用安裝套件。 ADO 用的方法超級簡單： 監聽你在 Build Agent 裡面的 console 輸出 。 對，就是 stdout。 你只要在 Pipeline 運行的 script 裡面 echo 一行特定格式的字串： echo "##vso[task.uploadsummary]...

程式碼品質，絕對是每個專業開發團隊都會遇到的課題。 你知道的，當系統上線後，突然收到資安通報說發現了安全性漏洞，需要緊急修補。更糟的是，這個漏洞在開發階段就可以避免，只是當時沒人發現。然後你開始翻 Commit 紀錄，發現那段有問題的程式碼正是自己幾個月前寫的…這種情境難免會讓你冷汗直流。 這是為什麼我們需要在 SAST(Static Application Security Testing，靜態應用程式安全測試)與源碼掃描的原因。它就像是你的程式碼守門員，在你還沒意識到問題之前，先幫你把那些潛在的地雷給挖出來。 SAST 與 SonarCloud 的關係 靜態程式碼分析，也就是我們常說的原碼掃描，它不是去執行你的程式，而是透過搜尋常見的程式碼撰寫樣式，嗅出程式碼中可能的安全漏洞、程式碼壞味道(code smell)、技術債、還有那些可能會在半夜讓你接到客戶電話的潛在bug。 SonarCloud 則是 SonarSource 提供的原碼掃描雲端服務版，它基於知名的 SonarQube，但你不用自己架設伺服器、不用煩惱維護更新，申請完直接使用就行了。 對於使用 Azure DevOps 的團隊來說，兩者更是天作之合，因為官方有提供極其簡單好用的 Tasks 支援，整合起來超級輕鬆，幾個步驟就搞定。 而且，SonarCloud 支援超過 25 種程式語言，從 C#、Java、JavaScript 到 Python，基本上你想得到的它都有。它不只找出你的程式碼潛在問題，還會告訴你為什麼這段程式碼會是個問題、以及該怎麼修復，甚至連預估要花多少時間修復都幫你算好了。 我在 2020 年寫過一篇關於在 Azure DevOps Build Pipeline 中整合 SonarCube 的文章。但你也知道，科技業的時間流速跟外面不太一樣，四年過去了，很多東西都變了。 所以，是時候來個 2026 年的更新版了。 開始動手 : SonarCloud 帳號申請與設定 好，廢話不多說，我們直接開始。 首先，你需要一個 SonarCloud 雲端帳號。如果你有 Azure DevOps 帳號，就可以直接用它以 SSO 方式登入 SonarCloud，不用再另外註冊帳號。 你可以前往 https://SonarCloud.io/ ，選擇用 Azure DevOp...

下課後，有個學員帶著問題走了過來， 戴著一幅黑框眼鏡，看起來就是那種勤奮型的人。 「老師，想請教你個問題」他說，「不知道你怎麼安排時間學習新的技術的? 現在 AI 發展這麼快，每天都有新東西出來。今天這個模型紅了，明天那個工具又說是必學。我根本不知道該從什麼地方開始，感覺永遠追不完…」 我點了點頭，收拾著背包。 這問題，我打從 AI 還沒出現的年代，就被問到現在。 說實在的，這年頭當開發者，挺累。 你打開社群網站，滿滿都是「不學這個你就落伍了」的暗示、 「202x 必學的 10 個技術」讓大家一窩蜂地膜拜新功能，那怕根本不知道那是幹嘛用的。 焦慮感一波一波襲來，搞得你晚上睡覺都不安穩。 但我想告訴大家一個事實： 其實，你永遠學不完的。 真的，別再想了。接受這個事實，你會輕鬆很多。 問題不在「學什麼」，而在「為什麼學」 我反問他：「你為什麼想學？」 他愣了一下，「因為…大家都在學啊。」 (我心想：又來了，面對熊來了，大家都只是想跑得比身邊的人快一些，是吧? 🤔) 大部分人學東西，是因為害怕。怕跟不上，怕被市場淘汰，怕面試被問倒。 所以瘋狂囤課、狂買書、把教學平台的購物車塞得滿滿的。結果呢？買了一堆課，上了5分鐘就放著長灰塵。 其實這不是學習，這是焦慮的發洩出口而已。 教育訓練從販賣知識變成販賣焦慮，我想作者本人應該也不願意吧。 其實，真正有效的學習，永遠從 解決問題 開始。 你現在手上有什麼專案？遇到什麼問題讓你卡關？你想做出怎樣的東西？從這裡出發，你才知道該學什麼。 不是「我要學完 Vue才能開始做專案」，而是「我要做這個功能，所以我得搞懂 Vue 的這個部分」。 差別在哪？前者你可能永遠學不完，後者你今天就能做出東西。 AI時代更要會「選擇」 如今，AI都會能自己程式了，直接 Vibe Coding 就好，還要學什麼？ 不，不是的! AI 越厲害，你越需要知道「該問什麼問題」。你得知道要做什麼、怎麼拆解問題、如何判斷 AI 給的答案對不對。 這些能力，從來都不是靠狂學一堆技術就能培養的。而是靠你真正去 做 、去 踩坑 、去 修bug 累積出來的。 (注意到關鍵字 修bug 了沒，這句是寫給想 Vibe Coding 的同學看的) 我常跟學員說，與其花三個月把一門課從頭到尾看完，不如花十天先做出一個爛爛...

這天 Azure DevOps 課程下課後，又有位學員留下來找我。 事情是這樣的… 他們公司政策規定要導入敏捷和ADO，但上完我的課程後，覺得有點困惑… (我內心OS: 呃? 怎麼會呢? 🤔 你不是應該上完我的課程後豁然開朗的嗎?) 他說，因為公司很多專案還是瀑布式在跑。需求從客戶那邊來的時候，動不動就是三個月、五個月這麼大包的東西。PM 離開技術圈一段時間了，也不知道該怎麼 end-to-end 切出一個迭代(兩周)內可以完成、又有價值的 PBI。 (我一邊聽，一邊想，覺得這是個難題沒錯，但其實最大的挑戰是心理障礙和習慣，因此…) 我跟他說：「其實把需求顆粒度切小，對每個人都有好處。對 PM、對客戶、對開發人員，全是利多。」 他笑的很無奈。 「這道理我可以理解，但我們的開發人員同時身兼好幾個專案，很難專注在某一個案子上。這時候，大家心態上就不想把顆粒度切小，因為怕時時刻刻被盯著要看進度。」 他停頓了一下，接著說：「所以開發人員寧願維持以前那樣一個功能做一個月、兩個月的顆粒度。這樣開發人員可以先去忙別的事情，最後幾天再來趕工。」 聽完，換我沉默想了幾秒。 因為這根本不是技術問題，也不是工具問題。這是整個組織的心態問題。 更深層的，是大家對「敏捷」的誤解。 很多人以為敏捷就是迭代、就是 Scrum、就是看板或站立會議。 但其實，真正的敏捷有一個很明顯的照妖鏡： 需求的顆粒度 。 沒有小的需求顆粒度，就沒有頻繁交付；沒有頻繁交付，就沒有敏捷。 我幾乎可以說，如果團隊無法把需求顆粒度變小，那敏捷導入十之八九是假的。 粗顆粒度的惡性循環 你在 Board(看板) 上看過那種預估要做三、五週的需求卡片嗎？ 「完成訂單管理功能」（預估五週） 「優化報表系統」（預估三週） 「整合第三方金流」（預估兩週） 每次看到這種，我就知道這個團隊有問題。 為什麼？因為一個需求如果要做兩週，在這兩週裡，這張卡片的狀態是什麼？「In Progress」? 但 In Progress 告訴了我們什麼？什麼都沒有。你不知道他做到哪裡了，可能才剛開始，也可能快做完了，也可能卡住了但不好意思說。 更慘的是，開發者在自己的 branch 上悶著頭寫了兩、三週的程式碼。等到要 merge 的時候，衝突、錯誤、邏輯不一致，問題才一個一個冒出來。然後就是...

開源 一個軟體或產品，要讓人信任它最簡單的方法，就是『開源(open source)』。 有時，用戶心裡會想：『我在你們這個技術上投資，萬一哪天你們整個開發團隊解散了怎麼辦? 我的投資不就打水漂了嗎? 』的確，這顧慮不無道理，產品的開發團隊也知道。 怎麼辦呢? 答案很簡單，就是『👉開源』。 怎麼讓用戶相信產品開發團隊在雲端上host的平台很正直，不會拿客戶上傳的資訊幹些什麼壞事? 答案也很簡單，又是『👉開源』。 總之呢，開源是快速獲取用戶信任的好方法。除了原始程式碼開源，最好連運行的環境也一併容器化，也開源。放上docker hub上讓大家可以免費下載。很佛心，沒錯，但它要換來的就是，你的信任和使用。 Dify 好唷，Dify 這個 2023年才開始的專案就是這麼幹的，這讓你可以比較放心這個其實只有20多人的新創團隊(而且還不是歐美血統)所開發的大語言模型 AI Agent 運行平台/框架。 Dify.AI 有一個雲端版本的 portal (如下圖)，功能面我先不在這篇文章說，這篇只講容器化，但讀者可以自行上網申請一個帳號體驗一下： 總的來說，Dify 對自己的定位是 LLMOps 平台，負責幫你代勞一堆有的沒的LLM相關整合大小事。(前面說了，這個你自己上網查或申請個帳號去體驗一下) 我們來看它如何在地端環境執行，首先，它整個專案在 GitHub上，可以透過底下指令下載： git clone https://github.com/langgenius/dify.git clone 下來之後，進到 \dify\docker 資料夾： 接著透過 docker-compose指令： docker-compose up -d 來運行，接著稀哩哩嘩啦啦的執行一陣： 接著你可以開啟 http://localhost/install ，進入整個系統的設定畫面： 設置好帳密之後，以後就可以透過 http://localhost/apps 網址登入站台囉： 整個畫面跟前面說到的 Dify.ai 網站完全相同，等於是你可以把人家整個網站 host 一份在自己的地端伺服器上，確保你的投資(例如設計的 AI Agent) 不會變成孤兒。 而我們在雲端設計好的 AI Agent，也可以透過匯出 DSL，直接在地端匯入： 匯...

以前，要做一個 AI Agent，光是想怎麼讓它跟外部系統溝通，就足以讓人頭痛。 但現在不同了。 Dify 與 MCP：天作之合的組合技 先說說 Dify 。如果你還沒用過它，那真的該好好認識一下。Dify 是一個開源的 LLM 應用開發平台，整合了視覺化的工作流程編輯器、RAG（檢索增強生成）管道、AI Agent 開發能力、模型管理等功能。簡單說，就是把原本複雜的 AI 應用開發，變成拖拖拉拉就能搞定的事情。 然後，另外是 MCP （Model Context Protocol）。這是 Anthropic 推出的協議標準，目的是讓 AI 模型能夠標準地串接各種外部工具、與不同的資料來源溝通。 試想一下，以前當我們想讓 AI 接資料庫、串 API、整合各種企業內五花八門的資訊系統時，每套都要自己刻一個介面。有了 MCP，這些都變成像是標準化的「插頭」，插上去就能用。 當這兩個東西碰在一起，會發生什麼事？ 讓流程無所不能的魔法 有了 MCP 之後，Dify (開發的AI Agent) 能做的事情突然變多了。 更讚的是，我之前做了一個小工具，可以把 Dify 直接串到 LINE OA(官方帳號) 上。現在要設計一個 AI Agent？ 輕鬆到太過美好。 以前要花兩週處理的工作，現在可能半小時就搞定了。 實戰：用 MCP 串接請假系統 直接看個案例。 底下這張圖片就是 Dify 串接 MCP 請假系統進行請假的畫面。看到了什麼？對話介面相當乾淨(下圖右方)，使用者只需要自然地說「我要請假」，AI Agent 就會自動處理剩下的流程，蒐集請假所需要的資料，然後透過MCP呼叫串接好的HR請假系統的 API，完成請假功能。 當然，查詢剩餘請假時數，也是如此。 這背後發生了什麼？AI 透過我們做好的 MCP Tools，呼叫了請假系統的 API，確認你的假別、假期餘額、代理人…等資訊。所有這些複雜的商業邏輯，都被優雅地包裝在 MCP Server 裡面。使用者完全感覺不到複雜性，就像在跟一個很聰明的 AI 聊天助理對談而已。 這就是 MCP 的魅力。 它不只是一個協議，更是一個思維模式的轉變——把複雜的系統整合，變成簡單的行動，讓AI Agent可以在與用戶對話互動中隨時調用。 用 .NET Core 打造你的 MCP Server ...

為何有這種需求 最近在上 Azure DevOps 課程，下課後，一群學員突然跑來問了個問題。 「老師，我們公司有三十幾個 Azure DevOps 專案，每個專案都有自己的 repo，每個 repo 都有自己的 pipeline yaml 檔…」他頓了一下，臉上帶著某種「歷盡滄桑」的表情，「有沒有辦法讓這些 pipeline 共用同一份 template？改一次就全部生效的那種？」 我其實急著下課，並沒有聽得很仔細，腦袋裡還在糾結：「為何要讓所有的 repo 都共用同一份 yaml template，每個開發專案不是應該有自己的 pipeline design 嗎？為何要為了統一控管搞得這麼複雜？」 於是我追問：「為什麼會有這種需求呢？」 他苦笑著說「每當公司想要在 pipeline 裡加入一些共用的步驟，比如說安全掃描、程式碼品質檢查、部署前的驗證等等，我們就得一個一個 repo 去改 pipeline yaml 檔。三十幾個專案，每個專案又可能會有好幾個 repo，改起來超級累人。」 教室裡其他學員也紛紛露出「我懂我懂」的表情。這種痛，做 DevOps 的人應該都瞭。 更慘的是，當你好不容易改完三十幾份檔案，過兩個月主管又說：「欸，我們現在還要加入程式碼品質檢查。」然後你又要再改一輪。如果哪天發現其中一個步驟寫錯了，想改？好啊，三十幾個 repo 再巡一次。 這就像是複製貼上了三十幾份同樣的食譜，結果發現鹽放太多了，然後你得把三十幾本筆記本都翻出來，一本一本改。真的累。 「所以…」學員問，「有沒有辦法讓這些 pipeline 共用同一份 template？改一次就全部生效？」 我當下趕著回家，沒多想，也來不及具體回答。 但回家後仔細思量：「這個問題其實挺實際的，應該是有解決方案的吧?」稍微翻了一下，果然發現 Azure DevOps pipeline 原本就支援引用外部的 yaml template。 如何實現？ Azure DevOps 其實早就想到這個問題了。它提供了一個機制，讓你可以把 pipeline 的某些步驟抽出來，放到另一個 repo 裡當作「模板」，然後其他專案的 pipeline 就可以「引用」這個模板。 聽起來很簡單對吧？但實際上第一次設定的時候，總會有那種「欸這樣寫對嗎?」的不確定感。 我也是這樣，看著官方...

11/29 ，我在 .net conf Taiwan 2025 的分享，題目是 『變革👉面對變革』，主要想談的是 LLM 在軟體開發領域(SDLC)中，這三年所帶來的改變。以及，如何面對。 關於『如何面對』這個部分，因人而異，我也就不想在這邊多說些什麼了。 但從 2022/11/30，一直到今天(2025/11/30)，AI對軟體開發帶來哪些改變，我倒是整理出了一些影片，也是我在這次會場中分享的部分內容，做為這一季也是 .net conf 2025 我自己場次的小總結，也分享給大家。 有些影片沒有聲音，原因是那是用來配合我在在講台上的講解所錄製，大多不長，讀者可以自己腦補體會一下。 我想表達的是， LLM在SDLC的每一個階段，都已經留下了深刻而無法抹滅的痕跡。不管你願不願意，未來AI都會與你一起開發系統，沒有例外。 開發階段AI帶來的改變(AI輔助開發): 這一段我想說的是，從2023年到2025年，AI在程式碼撰寫這個領域，介入的愈來愈深，愈來愈廣。從『只是這樣?』，到『原來可以這樣』… 2023年盛行的 Code Suggestion(程式碼片段生成或建議) https://youtu.be/gPGE-Tze_sk 2024年盛行的 Agent Mode(IDE內的大範圍生成) https://youtu.be/v6PI9Fbt7Oo 2025年開始的 CLI(命令列模式大範圍修改或生成) https://www.youtube.com/watch?v=MnbEhg3JWq4 當天做的一個現場小調查，你會發現，在今天，軟體開發就等同於AI輔助軟體開發，幾乎沒有例外： 需求設計階段AI帶來的改變： 如果你願意，AI也可以產生需求規格。甚至，從產生需求規格一路自動到完成開發… User Story/AC 自動生成 https://www.youtube.com/watch?v=AxtYwBUMIyM 搭配MCP，從規格自動完成功能開發 https://www.youtube.com/watch?v=Yp9UImcfWfs CI階段AI帶來的改變： AI的大幅度介入，將會讓人類成為開發的瓶頸，而有趣的是解決這個瓶頸的鑰匙，也是AI。現在透過AI，可以協助人類做 code review，在測試左移(shift ...

今天在 Build School 上課時發生了一件事，讓我想了想之後，還是決定寫篇文。 事情是這樣的。 上課時，我問學員：「如果有一個敏捷團隊，裡面大概 5-7 位成員，在一個迭代中同時開發 3-5 張需求卡片，你們覺得應該切幾個 feature branch?」 本來以為會聽到各種答案。 有人會按功能切、會按人頭切、或是按模組切…，因為我曾經聽過各式各樣的回答。 結果，他們所有人異口同聲：「只切一個分支。」 我愣了一下。「只切一個？」 「對，一個。」 這群學員才剛學 Git 沒多久，怎麼得出這個『違反常理』的結論的？上了這麼多年課，每次談到這個議題，學員都還可以跟我糾結半天，討論到底要不要用 Git Flow。 後來，助教跟我解釋，原來他們之前讓學員自己做了實驗。 什麼實驗? 實驗很簡單，因為反正要做專題，所以把學員幾個人分一組，讓他們用不同的分支策略跑幾個迭代。有些組按人切分支，有些按功能切，有些混著切。然後看看哪種方式最順。 結果呢？ 用多分支的組，第一個迭代還算順利，大家各寫各的，感覺井然有序。但整合的時候就開始出事了。功能 A 做完了，但要等 B 跟 C 才能 merge。有人幾天沒事做，只能坐著等。 到第二個迭代，問題更大。大家在自己的分支上寫了一段時間，最後 merge 時才發現衝突一堆。有些衝突好解，但有些是邏輯上的衝突，或是使用了同樣功能的不同套件，兩個人改了同一個模組的不同地方，單獨看都沒問題，合起來就爆了。 第三個迭代，有人開始崩潰。明明功能做完、測試也過了，但因為流程卡在 release branch，要等到迭代結束才能部署。一個小 bug 改了五分鐘，卻要三天才能上線。更慘的是，有人說：「程式碼寫完過了很久才整合，開始忘記當初為什麼要這樣寫了。」 最後，讓他們自己試試看：如果大家都在同一個分支上開發會怎樣？ 結果出乎所有人的意料之外。 衝突變少了(其實是變多了，但因為每天都在整合，有問題馬上發現，立刻解決，所以花在解決衝突的時間反而變少了)。部署變快了，一個小功能做完，就能立刻上線。整個團隊的節奏順暢很多，不用再有人乾等。 助教說：「他們自己體驗過就懂了，不用我們特別去教。」 聽完之後，我想了很久。 DORA 指標 其實他們體驗到的，就是 Google 研究出來的 DORA 指標在講的事情。 ...