lguidolin/設計先行

先設計，再建置

概述

工作依序經過五個階段：腦力激盪 → 規格 → 計畫 → 執行 → 記錄。在設計清楚闡述並獲得批准之前，不進行任何實作。最簡單的任務，往往是未經審視的假設付出最高代價的地方。

違反這條規則的文字，就是違反它的精神。 「邊寫程式邊設計」並不是設計。

五個階段

1. 腦力激盪。 探索意圖、限制條件與成功標準。一次只問一個問題。提出 2–3 種方案，包含權衡取捨與建議。收斂到一個設計，並獲得明確批准。此階段不寫程式。
2. 規格。 將批准的設計寫入一份標註日期的文件。規格是建置內容的契約。
3. 計畫。 在觸碰程式碼之前，將規格分解成一個有序、可審查的實作計畫。
4. 執行。 根據計畫實作，並設定審查檢查點。
5. 記錄。 將建置的內容與原因提煉成決策記錄（參閱 recording-decisions）。

分解大型工作。 如果需求涵蓋多個獨立的子系統，請在深入細節之前先進行分解。每個子專案獨立運作自己的週期，並按照依賴順序建置。

何時不使用

真正瑣碎且可逆的修改（例如錯字、日誌行、設定值）可直接跳至執行階段。判斷標準：錯誤猜測的成本是否高於設計步驟？ 如果是，則先設計。

常見的合理化藉口

藉口	現實
「這個太簡單了，不需要設計」	簡單的任務隱藏著假設。花幾句話做設計很便宜；重寫程式碼則不然。
「我邊寫邊設計」	在設計確定之前寫的程式碼，就是要重寫的程式碼。設計是獨立的一項活動。
「使用者已經告訴我要建置什麼了，那就是設計」	需求只說明什麼，而非如何做。如何做才是設計。
「先探索程式碼庫就能知道做法」	探索可以輔助設計，但不能取代對單一設計方案的批准。
「我們很趕時間」	趕時間的時候，正是省略設計會產生白做工結果的時候。

紅旗警訊 — 立即停止

• 在存在已批准的設計之前就打開編輯器
• 「讓我先快速做個原型」沒有規格的原型就是未經審查的範圍
• 在沒有計畫的情況下開始一個跨多個檔案的變更
• 將使用者一行字的需求視為完整的規格

所有這些都代表：停止、設計、取得批准、然後建置。

完整理由說明：憲法第一條，收錄於 engineering-constitution/references/engineering-constitution.md。