category
這裡整理與「架構設計」相關的已發布文章，依最新更新排序。
Latest first
2026 iThome 鐵人賽 AI CleanCode Day 33：安安～我是ChiYu～ 三十三天前，我手上其實只有三份材料：一本 753 頁、厚度大約五、六公分的《無瑕的程式碼 第二版》，兩則 Uncle Bob 談 Coding Agent 的 X 貼文，以及這段時間大量使用 AI Coding …
2026 iThome 鐵人賽 AI CleanCode Day 32：安安～我是ChiYu～ 昨天，我把前面累積的 24 份 Policy 分別放回適合的位置：跨 Repository 可重用的判斷進入 Skill，專案自己的領域語言、架構與測試規則留在 Repository，風險接受與最後決策仍由工程師…
2026 iThome 鐵人賽 AI CleanCode Day 31：安安～我是ChiYu～ 昨天，我重新走了一遍這三十天從 Clean Code 延伸到 CLEAN 五原則的過程，才發現前面的文章已經累積了 24 份 Policy。 單篇看都不長，全部塞進 AGENTS.md 卻會產生新的問題：Agen…
2026 iThome 鐵人賽 AI CleanCode Day 30：安安～我是ChiYu～ 昨天，我拒絕把 AI 給出的 48、84、156 小時直接當成承諾，因為那些數字缺少足以支撐它們的來源、假設與失效條件。 寫到 Day 30，我想先把這個系列最核心的問題正式回答一次：CLEAN 五原則，到底是怎…
2026 iThome 鐵人賽 AI CleanCode Day 29：安安～我是ChiYu～ 昨天，我比較了多個 Agent 平行開發時的實作、整合、Review 與接手成本。兩條開發線都能完成任務，但整個團隊有沒有變快，還得把後面的整合與接手算進去。 只要有人問：「這個需求多久可以完成？」我們卻很容易再…
2026 iThome 鐵人賽 AI CleanCode Day 28：安安～我是ChiYu～ 昨天，我把一項通知重試需求拆成三個小週期，讓 Agent 每完成一段就取得測試回饋與回退座標，避免單一開發流程一次累積太多風險。 今天，我把開發線從一條增加到兩條：兩位 Agent 從相同 Commit 同時開工…
2026 iThome 鐵人賽 AI CleanCode Day 27：安安～我是ChiYu～ 昨天，我把 AI Agent 的完成宣告整理成可重跑的 Evidence Packet：固定產品版本後，連同 Prompt、Diff、Build、Tests、Smoke、限制與失敗紀錄一起保存。下一位工程師因此能…
2026 iThome 鐵人賽 AI CleanCode Day 26：安安～我是ChiYu～ 「Build 成功、測試全綠、需求完成。」 這三句，我在 AI Agent 的完成回報裡看過很多次。看起來很完整，卻沒有交代驗證的是哪一份 Code、實際跑了哪些檢查，也沒有說綠燈在哪裡停止。 昨天修正人工重送功…
2026 iThome 鐵人賽 AI CleanCode Day 25：安安～我是ChiYu～ 昨天我補強了 Dependency Rule 與 Architecture Test，確保 Use Case 不會直接依賴資料庫或外部 SDK。不過，那組測試只守住 Use Case；Controller 仍能另…
2026 iThome 鐵人賽 AI CleanCode Day 24：安安～我是ChiYu～ 昨天剛把 EF Core 與通知 SDK 留在 Use Case 外圍，今天我就故意把 WorkItemsDbContext 加回 OverdueWorkItemProcessor 的建構式。Release Bu…
2026 iThome 鐵人賽 AI CleanCode Day 23：安安～我是ChiYu～ 昨天整理元件邊界時，我保留了既有通知 Port，卻也發現一個不能忽略的問題：它接收的參數仍是 EF Core 使用的 WorkItem Entity。表面上隔離了通知 Provider，核心實際上還在說 Pers…
2026 iThome 鐵人賽 AI CleanCode Day 22：安安～我是ChiYu～ 昨天，我把工作項目的生命週期與通知傳送拆成兩條 Use Case，但它們仍在同一個 API Host 裡執行。通知流程只認得 IWorkItemNotificationSender，實際使用 Demo 還是 Qu…
2026 iThome 鐵人賽 AI CleanCode Day 21：安安～我是ChiYu～ 昨天，我把會獨立改變的重試規則從 Dispatcher 分離出來。但打開目前的 Solution，裡面早已有三個正式 Project，Build 後也會產生多個 DLL。這是不是代表架構早就取得獨立性了？ 還不一…
2026 iThome 鐵人賽 AI CleanCode Day 20：安安～我是ChiYu～ 昨天，我們處理了 HTTP 與背景 Worker 同時選中同一筆 Work Item、進而重複送出通知的問題。資料更新、通知傳送、失敗重試與取消路徑，也都有對應測試。 從行為價值來看，昨天的需求已經完成。不過，測…
2026 iThome 鐵人賽 AI CleanCode Day 19：安安～我是ChiYu～ 昨天加入背景 Worker 後，逾期流程多了第二個入口：使用者可以透過 HTTP 主動觸發，Worker 也會依排程執行，最後兩邊都呼叫同一個 IOverdueWorkItemProcessor.ProcessA…
2026 iThome 鐵人賽 AI CleanCode Day 18：安安～我是ChiYu～ 昨天談完元件原則後，Work Item API 已經形成三個清楚的責任區域：API 處理 HTTP、資料與通知流程，WorkItems.ServiceLevel 保存共用的 SLA 規則，Reporter 則是只…
2026 iThome 鐵人賽 AI CleanCode Day 17：安安～我是ChiYu～ 昨天整理完通知的行為契約、Consumer 需要的能力與原始碼依賴方向後，系列接續版本仍只有一個 Production Project。IWorkItemNotificationSender 由高階 Use Ca…
2026 iThome 鐵人賽 AI CleanCode Day 16：安安～我是ChiYu～ 昨天把服務等級與派工政策分開後，今天我在共同通知介面後方，再放入一個 Queued Provider。Provider 就是負責實際送出通知的替代實作。 Demo 與 Queued 都能實作同一個 Interfa…
2026 iThome 鐵人賽 AI CleanCode Day 15：安安～我是ChiYu～ 昨天只有兩條通知升級規則，而且都由同一位服務等級政策負責人維護。我因此把判斷集中在 RequiresEscalationNotification，沒有再建立 Interface 或規則集合。對當時的需求來說，一個…
2026 iThome 鐵人賽 AI CleanCode Day 14：安安～我是ChiYu～ 前天談測試紀律，昨天接著確認整潔的測試與驗收測試能不能真的守住需求。今天，這個系列正式跨過 Part I〈程式碼〉，進入 Part II〈設計〉。 一進入設計，測試全綠就不再是最後答案。 同一個 Agent 交出…
2026 iThome 鐵人賽 AI CleanCode Day 13：安安～我是ChiYu～ 昨天談測試紀律時，我比較了直接完成、TDD 與 TCR。那些實驗回答的是：測試何時介入，會怎麼改變 Agent 的前進節奏與還原範圍。 今天遇到的問題更麻煩：測試介入得很早，不代表測試問對了問題。 在產品範例驅動…
2026 iThome 鐵人賽 AI CleanCode Day 12：安安～我是ChiYu～ 昨天比較類別拆分時，控制組、行數上限與內聚拆分都能把升級通知做對，也都通過最後的行為驗證。 若只看終點，三種結構都像是成功的候選。可是最後一片綠燈，只能證明它們抵達了終點，沒有說明途中累積了多少尚未驗證的修改，也…
2026 iThome 鐵人賽 AI CleanCode Day 11：安安～我是ChiYu～ 昨天我先釐清 WorkItem、DTO 與 EF Entity 各自負責什麼。最後沒有建立第二套 Domain Model，只把指派、完成與逾期狀態轉換收回 WorkItem。 物件角色清楚之後，新的問題也浮了出…
2026 iThome 鐵人賽 AI CleanCode Day 10：安安～我是ChiYu～ 昨天我比較了一次重寫與分段 Commit，最後保留可以逐步驗證、失敗時局部還原的清理節奏。函式內部整理完後，我接著往物件邊界看，WorkItemsController 裡還留著幾行很直接的 Code： 這些 Se…
2026 iThome 鐵人賽 AI CleanCode Day 9：安安～我是ChiYu～ 昨天，我把同一項需求交給三種函式結構，觀察全新 Agent 會如何理解資料、又會把修改放在哪裡。我最後採用 CQS，但那只回答了資料目前該放哪裡，還沒回答修改走偏時要怎麼退回。 今天接著比較同一段清理工作：讓 Ag…
2026 iThome 鐵人賽 AI CleanCode Day 8：安安～我是ChiYu～ 昨天，我從三份函式拆分結果中選了 Stepdown 版本。 ProcessOverdue 現在可以由上而下讀成四個步驟：找出逾期候選、逐筆處理、儲存狀態、回傳結果。入口變清楚了，但一份結構是否真的好用，不能只看今天…
2026 iThome 鐵人賽 AI CleanCode Day 7：安安～我是ChiYu～ 昨天，我們替 Work Item 逾期流程保留兩則有測試依據的警告註解，也確認 Formatter 只能整理已設定的格式規則。 註解沒有逐行翻譯 Code，排版也整理好了。可是打開 ProcessOverdue，查…
2026 iThome 鐵人賽 AI CleanCode Day 6：安安～我是ChiYu～ 昨天，我們把 Work Item 逾期流程的命名規則寫進 Repository，讓 Agent 可以在安全範圍內自主命名。 名稱說清楚之後，我接著測另一個很常見的要求：補註解、整理格式，真的會讓程式碼更好讀嗎？ 這…
2026 iThome 鐵人賽 AI CleanCode Day 5：安安～我是ChiYu～ 昨天，我把逾期處理中的單筆流程抽成一個私有方法： ProcessOverdueItemAsync 看起來很像一個好名稱：有動詞、有處理對象，也保留非同步方法常見的 Async 結尾。 但只看呼叫端，我仍然得猜：它只…
2026 iThome 鐵人賽 AI CleanCode Day 4：安安～我是ChiYu～ 同一段四十多行的 Controller Action，我交給同一個 AI Agent，用兩種整理範圍各跑一次。 兩份結果都通過測試：一份把 Action 壓到十七行，另一份保留三十八行，只抽出單筆逾期處理。若只看行…
2026 iThome 鐵人賽 AI CleanCode Day 3：安安～我是ChiYu～ 昨天的 Agent 很有把握地寫下： 已完成逾期處理的 Clean Code 重構。 它確實改善了命名與閱讀順序，既有行為驗證也沒有發現漂移。可是看完這份完成報告，我沒有先問 Code 還能不能更漂亮，而是卡在一個…
2026 iThome 鐵人賽 AI CleanCode Day 2：安安～我是ChiYu～ 昨天，我真的把這句話交給了 Codex： 改善逾期處理，讓它符合 Clean Code。 Agent 最後交出一份看起來很成功的候選：能 Build、測試全綠，名稱更清楚，主要流程更短，Diff 也集中在逾期處理。…
2026 iThome 鐵人賽 AI CleanCode Day 1：安安～我是ChiYu～ 前兩個 iThome 鐵人賽系列，我從七月就開始準備；進入九月前，稿件也都如期完成。 照理說，這時候應該可以先喘口氣。可是在整理那兩個系列的過程中，我一直惦記著另一個題目，甚至覺得它可能會比原本的規劃更有意思。 但…
整理 Matt Pocock 與 Uncle Bob 的訪談重點，從 CRAP、變異測試、多 Agent 品質流水線，到我從 AI Coding 實作整理出的 CLEAN 五原則，思考工程師如何建立可驗證的信任。
Workflow Skill Router V2 把原本寫在 SKILL.md 裡的路由習慣，整理成會先驗證能力、再選擇路徑的 Codex 控制層；開發者仍可用 Personal 與 Workspace Profile 管理自己的 Skill Tree。
這是一份專為 2026 年 CIO/CTO 準備的 AI 導入全指南。從 ChatGPT、Claude、Gemini 的核心戰略對決，到企業最關心的資安治理、數據邊界與導入地雷，我們一次講清楚。
在 AI Agent 的架構中，SKILL 是讓大語言模型（LLM）與現實世界互動的核心橋樑。本文詳細探討 AI Agent SKILL 的定義、標準結構規範 (v1.0)，並提供高品質 SKILL 的撰寫指南與 DDD 思維的應用。
今天，我們要戴上「工程安全帽」，化身為系統架構師，規劃未來系統穩定、高效、可擴展的基石。
迭代器模式 (Iterator Pattern) 提供統一的方式遍歷集合元素，而不暴露內部結構。本文以 C# 音樂播放清單為例，示範如何輕鬆管理集合。
中介者模式 (Mediator Pattern) 集中管理物件間的溝通，降低耦合度。本文利用 C# 聊天室範例，示範如何簡化複雜的互動關係。
備忘錄模式 (Memento Pattern) 讓你能隨時保存並恢復物件狀態。本文透過 C# 遊戲存檔範例，教你如何實作狀態回復機制。
觀察者模式 (Observer Pattern) 讓物件在狀態改變時能自動通知所有依賴者。本文以 C# YouTube 訂閱通知範例，示範即時更新機制的實作。
狀態模式 (State Pattern) 允許物件隨內部狀態改變而改變行為。本文透過 C# 手機鈴聲模式範例，示範如何消除複雜的條件判斷。
策略模式 (Strategy Pattern) 讓你定義一系列演算法並能靈活互換。本文以 C# 交通工具選擇範例，示範如何提升程式的彈性與可維護性。
模板方法模式 (Template Method Pattern) 定義演算法骨架，將細節留給子類別實作。本文透過 C# 披薩製作範例，教你如何固定流程並保留彈性。
訪問者模式 (Visitor Pattern) 讓你在不改變物件結構下新增功能。本文以 C# 遊樂園設施範例，示範如何解耦資料結構與操作邏輯。
單例模式 (Singleton Pattern) 確保一個類別只有一個實例。本文透過 C# 範例，示範如何實作並應用於系統設定管理等場景。
工廠方法模式 (Factory Method) 讓你將物件建立邏輯封裝起來。透過 C# 披薩工廠範例，學習如何讓程式碼更具彈性與可維護性。
抽象工廠模式 (Abstract Factory) 能協助你建立一系列相關或相依的物件。本文以 C# 家具工廠為例，教你如何輕鬆管理產品系列。
原型模式 (Prototype Pattern) 透過複製現有物件來建立新物件，省去繁瑣的初始化過程。本文使用 C# 履歷表範例帶你實作。
建造者模式 (Builder Pattern) 將複雜物件的建構過程與表示分離。透過 C# 三明治點餐範例，學習如何一步步構建複雜物件。
介面卡模式 (Adapter Pattern) 就像轉接頭，讓不相容的介面能順利合作。本文以 C# 充電器轉接範例，示範如何解決介面衝突。
橋接模式 (Bridge Pattern) 將抽象與實作分離，讓兩者能獨立變化。透過 C# 遙控器與電視範例，了解如何降低耦合並提升擴充性。
組合模式 (Composite Pattern) 讓你用一致的方式處理個別物件與物件群組。本文透過 C# 檔案系統範例，示範樹狀結構的實作。
裝飾者模式 (Decorator Pattern) 讓你不需修改原有程式碼，就能動態為物件添加新功能。本文透過 C# 咖啡加料範例輕鬆學會。
外觀模式 (Facade Pattern) 為複雜系統提供統一的簡化介面。本文透過 C# 家庭劇院範例，示範如何讓系統操作更直覺、更好維護。
享元模式 (Flyweight Pattern) 透過共享物件大幅節省記憶體資源。本文以 C# 樹木生成範例，教你如何有效管理大量重複物件。
代理模式 (Proxy Pattern) 透過中介物件控制對目標物件的存取。本文利用 C# 檔案權限範例，示範如何實作安全控管與延遲載入。
責任鏈模式 (Chain of Responsibility) 將請求沿著處理鏈傳遞，直到被處理為止。本文以 C# 公文簽核範例，教你打造彈性的處理機制。
命令模式 (Command Pattern) 將請求封裝成物件，支援撤銷與排程。本文透過 C# 餐廳點餐範例，示範如何解耦請求發送者與執行者。
解譯器模式 (Interpreter Pattern) 用於定義並解析自訂語言。本文透過 C# 文字冒險遊戲範例，教你如何實作指令解析系統。
想寫出好維護、易擴充的程式碼？這篇文章帶你快速入門設計模式（Design Patterns），搞懂建立型、結構型與行為型模式的核心概念。