背景

這篇文章探討了在開發命令列工具（CLI）或自動化腳本時，實作 --dry-run（模擬執行）旗標的重要性。作者認為這不僅是為了防止災難性的誤操作，更是一種開發上的輔助，讓開發者在處理生產環境數據或執行具破壞性的操作前，能先驗證邏輯的正確性與預期結果。

社群觀點

Hacker News 的討論串顯示，開發者社群對於「模擬執行」的必要性有高度共識，但在實作細節與哲學上則有顯著的分歧。許多資深開發者傾向於採取更保守的預設行為，他們主張與其提供 --dry-run 旗標，不如讓工具預設就是「唯讀」或「模擬」模式，必須顯式加上 --really、--commit 或 --execute 等旗標才會真正執行變更。這種「預設安全」的設計能有效避免因忘記加上模擬旗標而導致的悲劇，特別是在處理涉及數十萬筆資料或刪除遠端機器的指令時。

在實作層面上，社群討論了如何避免模擬邏輯污染業務代碼。一種被廣泛認可的模式是「功能性核心與命令式外殼」（Functional Core, Imperative Shell），即將邏輯運算與實際執行分離。開發者建議將所有會產生副作用的操作（如資料庫寫入、API 呼叫）封裝在可注入的策略或介面中。在模擬模式下，系統僅調用日誌記錄器而非真實的執行器。這不僅能保持代碼整潔，還能確保模擬路徑與真實路徑盡可能貼合。有留言者提醒，如果模擬模式只是簡單地跳過邏輯並列印訊息，往往無法發現潛在的邊界錯誤；理想的模擬應執行到「寫入前最後一刻」，包含權限檢查與參數驗證。

此外，針對極高風險的操作，社群提出了一些比單純旗標更具強制性的「防呆機制」。例如，有些工具會要求使用者手動輸入隨機生成的驗證碼，或要求輸入主機名稱、甚至特定的短語（如 tarsnap 的 "No Tomorrow"）才能繼續。這類設計旨在打破使用者的「自動導航」慣性，防止因過度依賴上箭頭重複執行指令而產生的失誤。也有人提到，現代檔案系統如 ZFS 或 Btrfs 的快照功能，或是利用 Docker 的 OverlayFS 進行環境隔離，有時比在應用層實作模擬模式更為可靠且全面。

有趣的是，討論中也觸及了不同程式語言對此類設計模式的影響。部分開發者認為，強型別或函數式語言（如 Go、Rust、F#）能透過更優雅的架構（如 Monads 或介面注入）來處理模擬邏輯，而不需要像傳統物件導向語言那樣依賴繁瑣的設計模式。儘管對於 --dry-run 的命名與預設值仍有爭論，但社群普遍認同：在自動化程度越來越高的現代開發環境中，提供一個可預測、可驗證的執行預覽，是專業工具不可或缺的特質。

延伸閱讀

• NILFS2: 一種支援持續快照的日誌結構檔案系統，可讓使用者復原數秒前誤刪的檔案。
• Molly-guard: 一個防護工具，在使用者嘗試透過 SSH 關機或重啟伺服器時，會強制要求輸入主機名稱以確認操作。
• PowerShell 的 -WhatIf: PowerShell 內建的模擬執行機制，透過 SupportsShouldProcess 屬性提供標準化的模擬與確認介面。
• F# for Fun and Profit: 討論如何利用函數式編程模式取代傳統設計模式的資源。
• Claude Code / GitHub Copilot: 留言提到現代 AI 編碼助手在生成 CLI 工具時，通常會自動建議加入模擬執行功能。