Refactor code structure for improved readability and maintainability

Author: marsen

source/_posts/2025/sdd_spec_kit_water_fall.md

@@ -0,0 +1,195 @@
+---
+title: "[SDD 與 Spec Kit]傳統瀑布式開發（1975-2000）"
+date: 2025/10/30 16:36:06
+tags:
+  - 學習筆記
+---
+
+TL;DR
+
+## 當軟體開發還是一門工程學
+
+1970 年代，當軟體開發還是一門新興學科時，人們自然地從傳統工程領域借鑒經驗。
+
+蓋房子需要藍圖、造橋需要設計圖，那麼開發軟體當然也需要完整的規格文件——這個看似合理的類比，開啟了長達數十年的瀑布式開發時代。
+
+有趣的是，[瀑布式開發 - Waterfall](/assets/royce1970.pdf) 這個名詞首次出現在1970年 Winston Royce 的論文中
+
+但 Royce 其實只是點名在當時的主流方法，並且給這種方法一些批評與建議。
+
+只是產業界選擇性地抓住了 Buzz Word ”Waterfall” 並將其奉為圭臬，而忽略了他的警告。
+
+當然這也不是第一次業界扭曲軟體工程理論的原意。
+
+## 瀑布模式的黃金年代
+
+流程的確立
+
+瀑布式建立起一套看似完美的流程：
+
+### 需求分析 → 系統設計 → 實作 → 測試 → 部署 → 維護
+
+就像接力賽跑，一棒接一棒，每個階段都有明確的交付物和把關者。
+
+需求分析階段產出厚達數百頁的需求規格書（SRS, Software Requirements Specification），
+
+系統設計階段則有高階設計（HLD, High-Level Design）和低階設計（LLD, Low-Level Design）文件。
+
+這些文件不只是參考，而是具有合約效力的承諾。
+
+當時的人相信，只要文件夠詳細，開發就是照著做而已。
+
+甚至 UML 也在那個時代應運而生。
+
+### 角色分工的確立
+
+這個時期也確立了軟體開發的專業分工：
+
+- PM（專案經理）負責管理時程與資源，通常不懂技術
+- SA（系統分析師）負責理解業務需求，把業務語言翻譯成技術語言
+- SD（系統設計師）負責技術架構，畫一堆UML圖
+- PG（程式設計師）負責編碼實作，被視為「碼農」
+- QA（品質保證工程師）負責測試驗證，專門找碴
+
+這種分工暗示著「思考」和「執行」是可以分離的。
+
+會思考的人負責設計，會打字的人負責coding。
+
+這種階級觀念到今天都還沒完全消失。
+
+## 為什麼瀑布式曾經如此成功？
+
+### 無法失敗的時代背景
+
+在1980年代，一套企業系統可能要價數百萬美元，開發週期動輒2-3年。
+
+IBM的System/360開發耗資50億美元（相當於今天的400億），這種規模的投資容不得失敗。
+
+瀑布式提供了管理層最需要的東西：控制力(或許只是幻覺)。
+
+每個階段都有文件、有簽核、有人負責。出事了可以調出文件來看是誰的錯。
+
+這種「可究責性」讓高層睡得安心。
+
+### 適合當時的技術限制
+
+當時的開發環境是什麼樣子？
+
+- 沒有 Git，版本控制用 CVS/RCS 等集中式系統，或原始的複製資料夾
+- 早期沒有 IDE，主要用 vi 或 Emacs，90年代才有原始的 IDE
+- 編譯大型專案可能要等數小時
+- 測試主要靠人工，自動化測試工具原始且昂貴
+- 部署要半夜停機，通過實體媒介發布
+
+在這種環境下，改一行code的成本可能是現在的100倍。
+
+「想清楚再動手」不只是最佳實踐，而是唯一選擇。
+
+[個人經驗補充區]
+
+## 瀑布式的內在矛盾
+
+### 文件與現實的落差
+
+最大的問題在於：軟體是看不見、摸不著的。
+
+建築師可以做模型，讓客戶看到未來的大樓長什麼樣子。
+
+但軟體呢？畫了100張UML圖，客戶還是不知道系統用起來是什麼感覺。
+
+更慘的是，需求文件寫著「系統應支援多使用者同時操作」，但什麼叫「多」？
+
+10個？1000個？每個人心中都有不同的數字，直到系統上線當機才發現認知落差。
+
+### 溝通的斷層
+
+瀑布式假設資訊可以無損地傳遞，但現實是每一次傳遞都會失真，每一層次轉換都是風險：
+
+> 客戶說：「我要一個簡單的購物網站」
+>
+> PM聽成：「要有會員系統、商品管理、訂單處理、金流串接...」
+>
+> SA寫成：「系統應提供使用者友善的介面以利商品選購」
+>
+> SD設計成：「採用三層式架構搭配MVC模式」
+>
+> PG實作成：「if-else地獄加上全域變數」
+
+最後客戶看到成品：「這不是我要的！」
+
+### 變更的成本
+
+瀑布式最致命的假設是：**需求是可以預先確定且不會改變的。**
+
+但現實是，**客戶看到系統之前，根本不知道自己要什麼。**
+
+就像買衣服，不試穿怎麼知道合不合身？
+
+但在瀑布式的世界裡，改需求要走變更流程、要重新評估、要加錢加時間。
+
+結果就是：不是系統符合需求，而是需求被迫符合系統。
+
+Y2K：瀑布式的最後輝煌與警鐘
+1990年代末的千禧蟲（Y2K）危機，是瀑布式的最後一場大戲。
+面對明確、不可變更的需求（修正日期欄位從2位數改成4位數），瀑布式展現了它的優勢：
+
+需求明確：2000年1月1日是死線
+範圍固定：所有日期欄位都要改
+風險可控：測試案例可以預先定義
+
+全球企業投入6000億美元，有條不紊地完成了系統修正。2000年1月1日，世界沒有崩潰，瀑布式似乎贏了。
+但等等，為什麼當初設計時沒想到？為了省兩個byte的空間，結果花了6000億來補救？這暴露了瀑布式的致命傷：它假設人類可以預見未來。
+
+[個人經驗補充區]
+網路時代的衝擊
+1995年，Netscape上市，網路泡沫開始膨脹。突然間，遊戲規則全變了：
+
+產品生命週期從年變成月
+競爭對手不是隔壁公司，而是地球另一端的車庫創業
+使用者期待每週都有新功能
+「永遠Beta」成為新常態
+
+Amazon的Jeff Bezos提出「兩個披薩團隊」理論：團隊要小到兩個披薩就能餵飽。這完全違反了瀑布式的大兵團作戰思維。
+Google更狂，直接在logo上掛著Beta標籤好幾年。Gmail從2004年Beta到2009年，期間不斷推出新功能。如果用瀑布式，大概還在寫規格書的第五版。
+當你的競爭對手每週更新，而你還在等三個月後的UAT（使用者驗收測試），市場早就不見了。
+瀑布式的遺產
+仍然適用的領域
+諷刺的是，即使在2024年，某些領域仍然需要瀑布式：
+
+醫療設備軟體：FDA要求完整的文件追蹤，一個bug可能害死人
+航太系統：NASA的軟體開發依然遵循嚴格的階段審查
+金融核心系統：當你處理的是別人的錢，「快速失敗」不是選項
+
+這些領域的共同點是：錯誤的成本遠大於延遲的成本。
+文化的延續
+更深層的影響是，瀑布式留下的不只是流程，更是一種思維模式。
+即使號稱敏捷的團隊，骨子裡可能還是瀑布式思維：
+
+Sprint計畫會議開4小時，像極了需求分析會議
+Story Point估算變成了工時評估2.0
+Scrum Master變成了改名的PM
+Retrospective淪為抱怨大會，因為「流程是總部規定的」
+
+最諷刺的是什麼？很多公司的「敏捷轉型」本身就是用瀑布式規劃的：先導入Scrum、再導入CI/CD、最後導入DevOps。每個階段都有明確的里程碑和KPI。
+結語：理解過去，才能創造未來
+瀑布式開發不是錯誤，而是特定時代的最佳解答。
+它教會了產業很多重要的事：
+
+文件化的價值（雖然常常過頭）
+流程管理的重要（雖然常常僵化）
+品質控制的必要（雖然常常太晚）
+
+但當世界改變，堅持不變就是最大的風險。瀑布式的問題不在於它本身，而在於它假設世界是靜態的、可預測的、可控制的。
+可惜，軟體開發更像衝浪而不是蓋房子。你必須隨時調整平衡，回應每一個浪頭。
+下一篇，我們將探討敏捷如何試圖解決這些問題，以及為什麼「敏捷」最後也變成了另一種「瀑布」。畢竟，人類就是這麼喜歡把動詞變成名詞，把精神變成教條。
+
+註：本文部分數據來源於IEEE Software History、Computer History Museum資料庫。Y2K投入成本數據來自Gartner 2000年報告。
+[待補充個人經驗區塊]RetryClaude can make mistakes. Please double-check responses. Opus 4.1
+
+## 參考
+
+- [以前的程序员，除了敲代码，还得会画画【让编程再次伟大#42】](https://www.youtube.com/watch?v=RyGA6zBHcJg)
+- [RUP 統一軟體開發過程](https://zh.wikipedia.org/zh-tw/%E7%BB%9F%E4%B8%80%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E8%BF%87%E7%A8%8B)
+- [序列圖，UML 給軟體開發帶來的唯一好處](https://docs.mermaidchart.com/blog/posts/sequence-diagrams-the-good-thing-uml-brought-to-software-development)
+
+(fin)