三個 repo 同時動工:用 AI Agent 平行開發微服務的甜蜜與代價
一個功能跨三個微服務,用 OpenSpec 先釐清合約再派三個背景 agent 平行實作,30 分鐘壓縮原本 1-2 天的工作。但也踩到 RabbitMQ event 欄位名不一致的坑,讓跨服務 null 災難 debug 了半天。這篇記錄平行開發的做法、設計變更的代價,以及跨服務合約的教訓。
隨手寫寫,留下紀錄
一個功能跨三個微服務,用 OpenSpec 先釐清合約再派三個背景 agent 平行實作,30 分鐘壓縮原本 1-2 天的工作。但也踩到 RabbitMQ event 欄位名不一致的坑,讓跨服務 null 災難 debug 了半天。這篇記錄平行開發的做法、設計變更的代價,以及跨服務合約的教訓。
InMemory EF Core benchmark 不走 SQL,數字漂亮卻沒參考價值。改連真實 UAT 資料庫:用 CryptoHelper 解密加密連線字串、繞過 DisableOptimizationsValidator 驗證、GlobalSetup 加健康檢查,最後用信賴區間判讀 +3.3...
用 superpowers 的 brainstorming → plan → subagent-driven 工作流跑 write-blog skill 三輪迭代,iter-3 assertion 100% PASS、iter-4 總分 88.5,iter-5 加 few-shot 後反而退步 3 ...
記錄用 skill-creator 開發 Claude Code Skill 的完整流程,涵蓋 iteration benchmark、description 優化與 skill-creator-advanced 審核,兩輪迭代從 81% 做到 100% pass rate。
用 Claude Code 的 AI Agent 團隊(PM、工程師、Code Reviewer、QC)完成部落格從 Hexo 到 Astro 的全面重建,記錄 OpenSpec 流程與平行開發的實戰經驗。
雙重檢查鎖定 (Double-Checked Locking Pattern) 是另外一個常用的設計模式,用來減少並發系統中競爭和同步的開銷,常用來避免快取在同一時間被重複建立
單例模式是軟件工程中最著名的模式之一。從本質上講,單例是一個只允許創建自身的單個實例的類,通常可以簡單地訪問該實例
使用 DI 的時候,註冊服務的生命週期是個很重要的議題,用的好,節省記憶體。提升程式效率,用不好,則可能造成重大的異常錯誤
Repository 模式與 UnitOfWork 模式可說是充滿爭議,國外大神爭論不休,本篇不打算加入筆戰,只簡單提供幾個適合的應用的情境與範例
簡單工廠是相當易用的一種設計模式,當程式複雜度高的時候,可以利用此模式切割複雜度高的判斷式,抽離業務邏輯與建構式,讓業務邏輯單純