任何軟體系統都為利害關係人（Stakeholders）提供兩種價值：行為（Behavior）與結構（Structure）。
開發者的悲劇往往在於：他們知道兩者都重要，卻總犧牲後者來滿足前者，最終導致系統價值的崩毀。
一、軟體的兩個價值#
| 類型 | 定義 | 內容與焦點 (Content & Focus) | 利害關係人角度 |
|---|---|---|---|
| 行為價值 (Behavior) | 「做」什麼 | 功能需求、 修復 Bug、業務邏輯 | 常與賺錢或 省錢有關 |
| 結構價值 (Structure/Architecture) | 「是」什麼 | 架構設計、 程式碼的可讀性與可維護性 | 長期成本與 迭代速度 |
「軟體」的真義 (The meaning of “Soft” ware)
為什麼稱為「軟體（Soft-ware）」而非「硬體（Hard-ware）」？
因它被設計成「軟（Soft）」的——也就是易被改變。
- 需求改變時，軟體應能輕易地隨之調整
- 修改難度應只與「變更範圍」成正比，而不該與「系統形狀（Shape）」有關。
如果新增一個功能需要大幅改動既有架構，就代表系統變「硬」了
二、價值悖論：哪個更重要？#
Uncle Bob 提出一個極端思想實驗來證明結構的重要：
| 情境 | 軟體狀態 (結構 vs. 行為) | 結構/修改性 | 最終結果與價值 |
|---|---|---|---|
| A | 功能完全正常 (行為優異) | 無法修改（僵化） | 隨著需求變更， 它很快就過時， 最終毫無價值 |
| B | 功能目前無法運作 (行為不佳) | 容易修改（靈活） | 開發者可輕易修好它， 並持續適應未來需求， 它將持續保有價值 |
長遠來看，結構價值大於行為價值。
三、艾森豪矩陣的啟示：重要 vs. 緊急#
既然結構如此重要，為何開發者常忽略它？
因為混淆了「重要性」與「緊急性」。
- 行為（Behavior）： 通常是緊急的（Urgent）
- 結構（Structure）： 通常是重要的（Important）
利用艾森豪矩陣（Eisenhower Matrix）來檢視軟體開發的任務：
| 優先級 | 屬性 | 內容 | 處理方式 |
|---|---|---|---|
| 1 | 重要 且 緊急 | 核心功能的嚴重 Bug | 立即處理 |
| 2 | 重要 但 不緊急 | 架構設計、重構、測試 | 常是被忽略的重災區 |
| 3 | 不重要 但 緊急 | 瑣碎的功能微調 | 常被誤認為第一優先 |
| 4 | 不重要 且 不緊急 | 瞎忙 | 避免 |
Figure 2.1: Eisenhower matrix
開發者的常見錯誤：
我們往往把第 3 類（不重要但緊急）誤判為第 1 類，從而犧牲了第 2 類（架構）。
業務部門和管理者通常只看到「緊急性」（行為），他們不會自動意識到架構重要性。
四、為架構而戰 (Fight for the Architecture)#
如果管理者只在乎功能（行為），那架構（結構）該由誰負責？ 答案是：你（開發者）。
- 職責所在： 就像建築師有責告訴業主「這柱子不能拆」，軟體工程師的職責就是捍衛系統結構
- 必要鬥爭： 業務部門為功能而戰是其職責；開發團隊為架構而戰是你的職責。
這是場必要角力（Struggle） - 結論： 如果系統因為架構混亂而難修改，那是你的失職，不能怪罪需求變更太快