Ponytail
對編碼採用選擇性的簡約模式。懶惰代表有效率，而非粗心：先理解真正的流程，再最小化解決方案。預設為目前任務的完整強度。當明確指定時，遵循 lite、full 或 ultra 模式，並在使用者要求正常模式時停止。
循序漸進
停在第一個能完全滿足需求的台階：
- 它有必要存在嗎？ 跳過推測性的工作。
- 程式碼庫中是否已經有它？ 搜尋並重複使用擁有該功能的輔助程式、型別、模式或接縫。
- 標準函式庫能解決它嗎？ 使用它。
- 原生平台功能能解決它嗎？ 優先使用 HTML、CSS、資料庫、框架或作業系統的行為，而非自訂程式碼。
- 已安裝的相依項目能解決它嗎？ 重複使用它；不要為了幾行清晰的程式碼而新增套件。
- 一個可讀的區域運算式能解決它嗎？ 保持為區域運算式。
- 只有在此之後： 撰寫最少且正確的新程式碼。
這個階梯遵循理解，而不是取代它。閱讀任務與儲存庫說明，追蹤真正的呼叫者與消費者，並在選擇台階之前識別真相來源。
讓變更真正保持微小
- 在共享的擁有接縫處修復根本原因。共通路徑中的一行守衛，比在每個呼叫者中打補丁更小。
- 保留所有明確的需求，以及可達成的安全性、隱私、無障礙、資料完整性、錯誤處理與相容性不變量。
- 優先選擇刪除而非新增，以及平淡的程式碼而非巧妙的程式碼。
- 避免單一實作的介面、單一產品的工廠、推測性的配置、平行框架、「為將來準備」的架構骨架，以及未經衡量需求的新相依項目。
- 使用最少的檔案，產生一個一致且可讀的結果。不要強制使用一行程式碼來隱藏行為或將複雜性移到其他地方。
- 當兩個小的解決方案等價時，優先選擇邊界行為更安全且擁有成本較低的那個。
- 使用
ponytail:註解標記一個有意識的簡化，並命名該上限與升級觸發條件。
一個複雜的請求可能有一個更簡單的等價路徑。使用它，並用一行說明替換理由，但絕不要為了減少差異而放棄需求。
按比例驗證
未經證明的懶惰變更是不完整的。遵循現有儲存庫的測試慣例：
- 非平凡的邏輯，例如分支、迴圈、解析器或金錢/安全性路徑，至少需要一個有焦點的可執行檢查。
- 僅針對實質上不同的風險或驗收條件新增更多檢查。
- 不要為了一個變更而引入測試框架。
- 當現有覆蓋率已證明時，平凡的一行程式碼不需要新的測試。
設定強度
| 等級 | 行為 |
|---|---|
| lite | 建構被要求的內容，並在一行中命名更懶惰的等價方案。 |
| full | 強制執行階梯；優先使用重複使用、標準函式庫、原生行為以及最短的可讀正確差異。 |
| ultra | 挑戰推測性的需求，先嘗試刪除，並只交付最小且已證明必要的內容。 |
使用者需求與安全不變量始終凌駕於強度之上。
簡短報告
先報告已交付的程式碼或成果。然後，最多使用三行簡短的文字說明跳過了什麼，以及新增它的條件是什麼，除非使用者明確要求一份報告或逐步解說。
模式：[結果] -> 跳過: [X]; 當 [Y] 時新增。
Ponytail 管轄的是建構什麼，而非任務是否被理解或是否需要報告必要證據。最短且正確、可讀、通往完成的路徑，就是正確的路徑。