三思而後行：前期的前置作業 #

俗話說「三思而後行」（Measure Twice, Cut Once），這句古老的木工諺語同樣適用於軟體開發。造出高品質軟體的設計師，往往會使用高品質的前置實踐（Practice）。

3.1 前置作業的重要性 #

前置作業的核心目標在於降低風險。軟體開發中最常見的風險往往源自於糟糕的需求分析與專案規劃。我們越盡早清除這些主要風險，後續的開發工作就越能平穩進行。

然而，許多程式設計師並未做好準備工作，原因通常有三：

缺乏完成此項任務的專業技能。
無法抵抗「盡早寫程式」的慾望。
管理者輕視前置作業的價值。

如何說服管理者（與自己）？ #

若你的管理者輕視設計與規劃，你能做的最好處理就是教育你的老闆。我們可以訴諸邏輯、類比或數據資料來進行溝通。

自我應驗預言（Self-fulfilling Prophecies） 我們可以透過開發團隊的態度，來判斷專案是否已準備就緒。當團隊能從前兩種心態轉變為第三種時，代表準備工作已完成：
❌ 「我們最好立刻編碼，因為之後會有許多除錯工作要做。」（缺乏規劃導致的惡性循環）
❌ 「我們沒有為測試安排太多時間，因為將來不會發現多少缺陷。」（過度自信與缺乏風險意識）
✅ 「我們已詳細研究需求和設計，想不出在編碼與除錯期間還會遇到什麼大問題。」（充分準備後的自信）

3.2 不同軟體類型與對應做法 #

不同種類的軟體專案，需要在「準備工作」和「建構活動」之間取得不同的平衡：

商業專案：往往適用於高度迭代開發（Iterative）。規劃活動（計畫、需求、架構）與開發活動（建構、系統測試、品質保證）會互相交織進行。
攸關性命的系統：因為要求極高的可靠性，通常採用循序方法（Sequential），強調嚴謹的前置作業。

雖然迭代法通常比循序法省錢，但沒有一種開發能做到絕對的極端。較好的混合做法有二：

先詳細說明 80% 的需求（給予額外需求說明定量時間），再在專案進行中系統化地接納最有價值的新需求。
先詳細說明最重要的 20% 需求，並小幅增量開發其餘部分，之後再逐漸說明額外的需求和設計。

3.3 ~ 3.5 關鍵的前置作業清單 #

無論採用何種開發流程，我們都必須確保以下三項前置作業已到位：

1. 問題定義 (Problem Definition) #

這必須先於具體的需求分析。重點在於從客戶的角度，使用客戶的語言來描述問題，確保開發團隊解決的是正確的問題。

2. 明確需求 (Requirements) #

明確的需求能確保是「使用者在駕馭系統」，有助於避免爭論，並減少系統開發後的變更成本。

核心觀念：需求是專案成功的關鍵。
心態調整：雖然我們希望需求明確，但也必須接受「需求變更是客戶越深入理解專案後的必然結果」。

3. 軟體架構 (Software Architecture) #

架構是支撐細節設計的框架，決定了系統的概念完整性。一個完整的軟體架構應包含以下組成成分：

點擊展開：軟體架構檢核清單

在設計架構時，應考慮以下面向：

程式組織：系統的整體結構與模組劃分。
主要類別：核心的 Class 定義與職責。
資料設計：資料庫與數據結構的規劃。
業務規則：特定領域的商業邏輯。
使用者介面：UI 設計準則。
資源管理：記憶體、連線數等資源控管。
安全性：驗證、授權與資料保護。
效能：速度與回應時間的目標。
規模彈性（Scalability）：系統擴充的能力。
互用性：與其他系統介接的能力。
國際化／本地化：多語言與地區支援。
輸入輸出（I/O）：資料讀寫策略。
錯誤處理：例外狀況的捕捉與回報。
容錯性：系統在部分失效下的運作能力。
可行性：技術與資源是否能實現上述設計。

3.6 前置作業的時間與工作量 #

做足前置作業並非浪費時間，而是為了節省後續大量的修正成本。根據經驗法則，建議的投入比例為：

工作量 (Effort)：約佔總工作量的 10-20%。
時程 (Schedule)：約佔專案總時程的 20-30%。

這段時間與工作量應該被獨立規劃出來，不應與編碼階段混淆，以確保前置作業的品質。