歡迎來到軟體開發指南！
你有沒有試過在沒有說明書的情況下組裝複雜的樂高模型？或者試過把隨手抓到的食材扔進碗裡，想烘焙出精緻的蛋糕？結果通常是一場災難！
開發軟體也是一樣的道理。如果你想創作出真正能運作並解決問題的產品，絕對不能一坐下來就盲目地開始編寫程式碼。在本章中，我們將探討系統化問題解決方法（Systematic Approach to Problem Solving）。你可以把它想像成你專業的「路線圖」，指引你將一個模糊的想法轉化為精緻、可運行的軟體。
不用擔心某些術語看起來很生硬——我們會把它們拆解成任何開發者（包括你！）都能輕鬆跟上的簡單步驟。
1. 分析：我們到底在解決什麼問題？
在寫下任何一行程式碼之前，你必須先了解問題所在。分析（Analysis）階段的核心就在於聆聽需求與建立模型。
關鍵概念：
• 定義問題： 你必須清晰地說明軟體需要達成什麼目標。如果你連目的地在哪都不知道，就永遠無法抵達！
• 需求（Requirements）： 這些是透過與目標使用者（Intended users）溝通而建立的。他們需要什麼？什麼是他們「必須具備」的功能？
• 資料模型（Data Models）： 你需要為系統使用的資料建立一張「地圖」。舉例來說，如果你正在製作一個圖書館應用程式，你的資料模型就需要包含「書籍」、「會員」和「歸還日期」。
• 抽象化（Abstraction）： 這是一個用來表達簡單概念的大詞：移除不必要的細節。如果你正在為賽車遊戲建立模型，你需要知道車子的速度和操控性，但你可能不需要把點煙器或腳踏墊都建模出來。
「敏捷」之道：
課程大綱提到了原型化/敏捷開發（Prototyping/Agile approach）。在過去，人們傾向於一次性規劃所有事情。而在敏捷開發中，我們會先構建一個「迷你版本」（即原型/Prototype），展示給使用者看，收集回饋，然後再進行改進。這就像在正式上色前先畫草圖一樣。
快速回顧：
• 我們跟誰溝通？使用者。
• 我們移除什麼？不必要的細節（抽象化）。
• 為什麼要製作原型？為了儘早釐清需求。
重點總結：分析是在決定「如何做」之前，先搞清楚「做什麼」和「為誰做」。
2. 設計：繪製藍圖
現在你知道要建構什麼了，接下來你需要規劃如何建構。這就是設計（Design）階段。
這裡會發生什麼？
• 模組化結構（Modular Structure）： 你將大問題拆解成更小、更易於管理的「模組」（例如子程式或類別）。
• 介面（Interfaces）： 你決定這些模組之間如何溝通。例如，「登入模組」需要將使用者名稱傳送給「資料庫模組」。
• 演算法（Algorithms）： 在編寫程式碼之前，先規劃好程式的逐步邏輯。
• 使用者介面（UI）： 你設計使用者會看到什麼。是一個按鈕？一個選單？還是一個文字框？
日常生活中的類比：
想像你正在設計廚房。你不會隨手買個爐灶就隨便擺放。你會決定冰箱放在哪、需要多少檯面空間（模組化結構），以及管道和電線要如何連接（介面）。
常見錯誤：
千萬別跳過設計階段！學生常想直接進入編寫程式碼的環節。然而，沒有設計的程式開發就像蓋房子沒有藍圖——最終牆壁會對不齊，事後修正的困難度也會倍增。
重點總結：良好的設計使用帶有清晰介面的模組，讓軟體更易於開發與維護。
3. 實作：將計畫化為現實
這就是實際「寫程式」的地方。你將模型和演算法轉化為電腦能理解的程式碼（指令）。
實作的關鍵特點：
• 編碼與除錯（Coding & Debugging）： 撰寫程式碼並修復過程中不可避免出現的「臭蟲（Bugs）」。
• 邏輯推理： 你應該要能解釋為什麼你的程式碼可行，以及為什麼它是高效率的。
• 關鍵路徑（Critical Path）： 在大型專案中，某些任務比其他任務更重要。開發者會聚焦在「關鍵路徑」上——即為了確保整個專案成功，必須按時完成的任務。
你知道嗎？
即使在這個階段，你依然是在進行敏捷開發。你寫一點程式碼、測試它、給使用者看，然後進入下一個部分。這就是所謂的迭代過程（Iterative process）。
重點總結：實作是透過迭代（逐步進行）的方式，將資料結構和演算法轉化為可運行的解決方案。
4. 測試：它真的管用嗎？
你已經寫好了程式碼，但它真的能達成預期目標嗎？測試（Testing）不只是「運行一次程式」那麼簡單，它是一個嚴謹的過程。
三種測試資料類型：
你需要使用多種資料來對程式進行「壓力測試」。使用口訣 N.B.E. 來記住它們：
1. 正常資料（Normal Data）： 應該能正常運作的資料。（例如：當程式詢問年齡時，輸入「15」）。
2. 邊界資料（Boundary/Extreme Data）： 處於允許範圍邊緣的資料。（例如：輸入「0」或「120」作為年齡）。
3. 錯誤資料（Erroneous Data）： 完全錯誤的資料。（例如：當程式詢問年齡時，輸入「香蕉」）。好的程式不應該崩潰，而應當顯示有用的錯誤訊息。
驗收測試（Acceptance Testing）：
最後的挑戰！這是目標使用者親自嘗試軟體，看看它是否符合原始規格（Specification）的階段。如果他們說「沒錯，這解決了我的問題」，那你就過關了！
重點總結：務必使用正常、邊界和錯誤資料進行測試，以確保你的程式穩健可靠。
5. 評估：回顧反思
專案完成了……真的是這樣嗎？評估（Evaluation）階段是你評判最終系統的時刻。
我們如何評估？
我們會根據特定的準則（Criteria）來檢查系統：
• 它是否滿足分析階段中所有的使用者需求？
• 它是否有效率（執行速度快且記憶體佔用少）？
• 它是否易於使用（使用者介面直觀嗎）？
• 它是否易於維護（程式碼有良好註解，方便他人進行修正嗎）？
快速回顧箱：
1. 分析： 問題是什麼？（需求/使用者回饋）
2. 設計： 我們將如何架構它？（模組/演算法）
3. 實作： 開始建構吧！（編碼/敏捷開發）
4. 測試： 它會崩潰嗎？（正常/邊界/錯誤資料）
5. 評估： 這樣足夠好嗎？（準則/是否符合規格）
重點總結：評估不僅僅是關於程式碼是否能執行；而是關於系統是否真的有效地解決了使用者最初面臨的問題。