.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，直接在地端匯入： 匯...