兩種價值觀的故事 (A Tale of Two Values) #
任何軟體系統都為利害關係人（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 | 不重要 且 不緊急 | 瞎忙 | 避免 |
開發者的常見錯誤： 我們往往把第 3 類（不重要但緊急）誤判為第 1 類，從而犧牲了第 2 類（架構）。 業務部門和管理者通常只看到「緊急性」（行為），他們不會自動意識到架構重要性。
四、為架構而戰 (Fight for the Architecture) #
如果管理者只在乎功能（行為），那架構（結構）該由誰負責？ 答案是：你（開發者）。
- 職責所在： 就像受雇建築師有責告訴業主「這柱子不能拆」，軟體工程師受雇職責就是捍衛系統結構
- 必要的鬥爭： 業務部門為功能而戰是他們的職責；開發團隊為架構而戰是你的職責。這是場必要角力（Struggle）
- 結論： 如果系統因為架構混亂而難以修改，那是你的失職，不能怪罪需求變更太快