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

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

3.1 前置作業的重要性#

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

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

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

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

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

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

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

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

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

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

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

flowchart LR
    A["純迭代開發"] --- B["混合做法 2\n先定義 20% 需求\n增量開發其餘部分"]
    B --- C["混合做法 1\n先定義 80% 需求\n系統化接納新需求"]
    C --- D["純循序方法"]

    style A fill:#4dabf7,stroke:#339af0,color:#fff
    style B fill:#69db7c,stroke:#40c057,color:#000
    style C fill:#69db7c,stroke:#40c057,color:#000
    style D fill:#ff8787,stroke:#fa5252,color:#fff

    B -.- E(["推薦的混合做法"])
    C -.- E

    style E fill:#fff3bf,stroke:#fcc419,color:#000

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%

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