14.1 敏捷開發與慣例優於配置（Convention over Configuration）的生產力革命#

2001 年的雪鳥會議：程序員對瀑布的叛亂#

2001 年 2 月，17 位軟體方法論者在猶他州雪鳥滑雪場聚會，產出了一份三百字的宣言——敏捷宣言（Agile Manifesto）：

• 個體與互動 重於 流程與工具
• 可用的軟體 重於 詳盡的文檔
• 與客戶合作 重於 合約談判
• 回應變化 重於 遵循計劃

背景是對瀑布模型的普遍挫敗：需求文檔 → 設計 → 編碼 → 測試 → 上線的線性流程，在需求會變的世界裡註定失敗（布魯克斯《人月神話》1975 的「沒有銀彈」早就警告）。敏捷的前身們（極限編程 XP、Scrum）各有實踐，宣言把它們統一成價值觀而非流程。

社會史意義：敏捷是知識工作者對泰勒制管理的反叛——「人不是流水線上的螺絲」。它也是 1990s 網路泡沫中快速變化的商業需求的映射：商業迭代速度首次超過軟體開發速度，開發方法必須重造。

Ruby on Rails（2004）：敏捷哲學的代碼化#

如果說宣言是價值觀，Rails（DHH 從 37signals 的 Basecamp 中抽出）就是代碼化的敏捷。兩大支柱：

1. 慣例優於配置（Convention over Configuration）

傳統框架（Java 的 Struts/早期 J2EE）需要海量配置文件（XML 地獄）。Rails 的答案：

只要遵守命名慣例，配置可以消失。

資料表 users 自動映射到模型 User、控制器 UsersController、路由 /users——零配置自動成立。

哲學本質：慣例是編碼進框架的集體決策——把「每個專案重複做的決定」預先做掉。這是 Dijkstra「靠結構不靠紀律」（8.3）與 Python「只有一種做法」（12.1）思想在框架層的匯流：減少選擇 = 減少錯誤 = 加速開發。

2. 不要重複自己（DRY）

出自《程式設計師修煉之道》（1999）——知識的每一份表示應有唯一權威來源。Rails 的遷移、驗證、路由都由單一定義生成多方代碼。DRY 是「資訊不變量」的工程化。

「魔法」的辯證：生產力與可推論性#

Rails 的慣例驅動被讚為魔法，也被咒為魔法：

歷史的裁決是分層的：新創與中小應用擁抱魔法（Rails/Laravel/Next.js），超大規模系統傾向顯式化（Go 的「顯式優於隱式」）——生產力與可推論性的取捨隨組織規模移動。

敏捷的兩次變質（誠實的批判）#

第一次：敏捷的企業化（2005–2012）。Scrum 認證產業、儀式化的站立會議成為新的官僚形式——敏捷變成了它當年反對的「流程與工具」。宣言起草者之一的 Martin Fowler 多次嘆息「大多數『敏捷』組織徒有其表」。方法論的商業化必然稀釋其精神（與 OOP 的官僚化 10.3 完全同構）。

第二次：規模化的再官僚化（2010s+）。SAFe 等「大規模敏捷」框架把敏捷重新塞回層級組織——5000 人的組織無法真的敏捷，只能表演敏捷。這揭示了敏捷的根本邊界：它的有效範圍是小團隊 + 需求快速變化 + 可分解的系統。

敏捷的長期遺產#

• 迭代交付成為一切軟體的預設（含 AI 模型的迭代發布）
• 測試文化（TDD→CI/CD）：自動化測試成為品質底線——「可執行的規格」
• 持續整合/部署：DevOps 運動（2009+）繼承敏捷的節奏（Amazon 2011 年宣稱每 11.6 秒部署一次）
• Git 與開源工作流：分支、PR、code review 正是敏捷微觀化的載體
• 2020s 的 AI 迴圈：LLM 代碼生成 → 測試 → 修正的多輪 agent 工作流（17.1），本質是敏捷迭代週期壓縮到秒級——Agile 的終極形態是讓 AI 跑迭代

小結#

下一節：14.2 LAMP 到現代框架