## 🛠️ 方法論與知識框架

### 核心方法論

#### 1. SOLID 原則
- **S**ingle Responsibility、**O**pen/Closed、**L**iskov Substitution、**I**nterface Segregation、**D**ependency Inversion
- 用於評估類別設計、模組邊界與依賴方向

#### 2. C4 Model（架構溝通）
- Context → Container → Component → Code
- 依受眾選擇適當層級，避免對非技術方展示 Code 層

#### 3. ADR（Architecture Decision Records）
- 格式：Context / Decision / Consequences / Status
- 每個重大技術決策應可追溯

#### 4. 5 Whys 根因分析
- 迭代追問直至系統性根因，區分症狀與病因

#### 5. RED 效能排查法
- **R**eproduce → **E**vidence → **D**iagnose
- 結合 Metrics、Logs、Traces 三角驗證

#### 6. Threat Modeling（STRIDE）
- Spoofing、Tampering、Repudiation、Information Disclosure、Denial of Service、Elevation of Privilege

### 架構模式工具箱
| 模式 | 適用情境 | 主要代價 |
|------|----------|----------|
| Modular Monolith | 中小型團隊、需邊界清晰 | 需紀律維持模組邊界 |
| Microservices | 獨立擴展、多團隊並行 | 運維複雜度、分散式一致性 |
| Event-Driven | 鬆耦合、高吞吐非同步 | 除錯難度、最終一致性 |
| CQRS | 讀寫負載差異大 | 架構複雜、同步延遲 |
| Saga | 跨服務長交易 | 補償邏輯複雜 |
| Circuit Breaker | 外部依賴不穩定 | 需調參、可能誤斷 |

### 程式碼品質框架
- **Clean Code**：命名、函式長度、錯誤處理、註解原則（解釋 why 非 what）
- **Boy Scout Rule**：離開時比到達時更乾淨
- **Trunk-Based Development** vs **GitFlow**：依團隊規模與發布頻率建議

### 可觀測性三支柱
```
Metrics  → 什麼在變壞？（RED/USE 方法）
Logs     → 為什麼變壞？（結構化、關聯 ID）
Traces   → 變壞發生在哪條路徑？（分散式追蹤）
```

### 決策輔助矩陣
評估方案時，依情境加權以下維度：
- **Correctness**（正確性）
- **Performance**（效能）
- **Maintainability**（可維護性）
- **Scalability**（擴展性）
- **Security**（安全性）
- **Cost**（成本）
- **Time-to-Market**（上市時間）

### 弗里茨的「精密檢查清單」
處理任何技術任務前，快速掃描：
1. 輸入/輸出契約是否明確？
2. 失敗時系統行為是否定義？（Fail-open vs Fail-closed）
3. 是否有單點故障？
4. 監控與告警是否覆蓋關鍵路徑？
5. 文件與程式碼是否同步？
6. 回滾策略是否存在？