歡迎來到軟件開發的世界！
在本章中，我們將探討構建軟件的不同方式。如果你把一個軟件項目比作蓋房子，你肯定不會在毫無規劃的情況下就直接開始砌磚，對吧？你需要一套「方法論」（Methodology）——這其實就是一個專業術語，用來描述你的開發策略。
無論你是程式設計老手還是剛入門的新人，理解這些模型都至關重要，因為它們決定了團隊如何協作、項目的預算，以及最終產品是否真的好用！
1. 瀑布模型 (Waterfall Model)
瀑布式生命週期是一種「傳統」的開發方式。它遵循嚴格的線性順序。就像真正的瀑布一樣，水流（或項目進度）只會朝一個方向流動：向下。
它是如何運作的：
你必須完全完成一個階段，才能進入下一個階段。典型的階段包括：
1. 需求分析 (Analysis)（我們需要什麼？）
2. 設計 (Design)（它看起來/運作起來會是怎樣？）
3. 實作 (Implementation)（開始編寫代碼！）
4. 測試 (Testing)（程式會崩潰嗎？）
5. 評估/維護 (Evaluation/Maintenance)（用戶滿意嗎？）
優缺點分析：
優點：非常容易理解和管理。因為一切都在開始時規劃好了，每個人都清楚「成品」最終應該是什麼樣子。
缺點：非常缺乏靈活性。如果客戶在開發過程中改變了主意，你很難回頭修改。此外，風險也較高，因為直到最後階段，你才能看到軟件的可運作版本。
快速複習：當項目規模小、簡單且需求 100% 明確且不會改變時，使用瀑布模型最合適。
2. 敏捷開發方法 (Agile Methodologies)
敏捷開發並不僅僅是一種單一的方法，而是一種靈活的「哲學」。它不將項目視為一個巨大的工程，而是將其拆解成小而易管理的模塊，稱為迭代 (Iterations)。
它是如何運作的：
團隊會非常快速地產出一個小型、可運作的軟件部件，展示給客戶看，收集反饋，然後在下一個「衝刺」（Sprint）中進行改進。
優缺點分析：
優點：具備極強的靈活性。如果客戶改變主意，團隊可以在下一個迭代中做出調整。客戶全程參與，因此他們通常對最終成果非常滿意。
缺點：很難準確預測最終項目的成本或所需時間，因為計劃一直在變。此外，這需要客戶投入大量時間提供反饋。
冷知識：大多數現代應用程式（如 Instagram 或 Spotify）都是使用敏捷開發的。這就是為什麼你會每隔幾週就看到小型更新和新功能出現的原因！
3. 極限編程 (Extreme Programming, XP)
極限編程 (XP) 是一種特殊的敏捷開發方法。它專注於產出高質量的代碼，並致力於提升開發人員的工作體驗。
主要特徵：
結對編程 (Pair Programming)：兩名程式設計師坐在同一台電腦前。一人負責編寫代碼，另一人負責檢查錯誤。這聽起來好像比較慢，但實際上能有效防止 Bug！
頻繁發布 (Frequent Releases)：軟件的小型版本會非常頻繁地發布。
優缺點分析：
優點：代碼質量通常極高，Bug 極少。非常適合需求經常變化的項目。
缺點：成本很高，因為你需要支付兩個人坐在同一張辦公桌前的費用（結對編程）。此外，這對團隊成員的紀律性要求很高。
4. 螺旋模型 (Spiral Model)
螺旋模型的核心在於風險分析 (Risk Analysis)。如果你正在構建某個極其昂貴或高危險性的系統（例如飛機的飛行控制系統），你就會使用螺旋模型。
它是如何運作的：
項目以螺旋形式推進。每轉一圈，你都會經過四個階段：
1. 確定目標
2. 風險分析（可能會出什麼問題？這會不會太昂貴？）
3. 工程開發（構建原型）
4. 規劃下一圈
優缺點分析：
優點：它是高風險、大型項目的最佳模型。風險可以在很早的階段被識別並處理。
缺點：非常昂貴且耗時。你需要經驗豐富的「風險專家」來主導開發。
考試重點：如果考題提到「風險」(Risk)，那幾乎可以肯定是在考螺旋模型！
5. 快速應用程式開發 (Rapid Application Development, RAD)
RAD 的核心在於速度！它非常依賴原型製作 (Prototyping)，目標是盡快讓用戶體驗到軟件的「雛形」。
它是如何運作的：
開發人員不會撰寫厚重的需求文檔，而是直接製作一個軟件的「模擬版本」。用戶試用後說：「我喜歡這個按鈕，但請把那個菜單移走。」開發人員隨即進行修改並再次展示。
優缺點分析：
優點：開發速度極快。因為用戶通過反饋參與了「建造」過程，最終產品幾乎保證是用戶友好的。
缺點：不適合需要大量後台處理的系統（如複雜的資料庫）。它通常過於側重「外觀」(UI) 而忽略了「引擎」(邏輯)。
總結對比表
瀑布模型：最適合簡單、需求固定的項目。（不靈活但清晰）。
敏捷/XP：最適合需求變動頻繁的項目。（靈活但難以預測）。
螺旋模型：最適合巨大、昂貴或危險的項目。（專注風險但昂貴）。
RAD：最適合速度與用戶介面為優先的項目。（快速但可能缺乏深度）。
編寫與跟隨演算法
無論你使用哪種開發方法，你永遠都需要編寫和跟隨演算法。在軟件開發的語境中，演算法就是實作階段的「藍圖」。
別擔心，這看起來可能有點複雜：演算法只是一組解決問題的步驟指令。在軟件開發中，我們在寫程式碼之前會先使用偽代碼 (Pseudocode) 或流程圖 (Flowcharts) 來規劃這些演算法。這能確保無論最後使用哪種程式語言，邏輯都是正確的。
快速複習：常見誤區
1. 別搞混敏捷開發和 RAD：敏捷開發是一種關於迭代的廣泛哲學；而 RAD 則是專門關於使用原型來加速進程的特定方法。
2. 瀑布模型並非「不好」：學生常以為瀑布模型是「錯誤」的，因為它過時了。但其實對於小型、靜態的項目來說，它是完美的！
3. 結對編程不是「作弊」：在 XP 中，兩人合作是一種品質保證策略，而不是程式設計能力弱的表現。
恭喜你讀完了軟件開發部分的筆記！你現在已經掌握了管理項目的五大核心方法。做得好！