为什么你需要在命令行工具中添加 dry-run 选项

摘要

本文作者分享了在开发报表应用时实现–dry-run选项的经验。这个选项让命令只打印将要执行的操作而不实际执行，在开发测试中提供了快速反馈和安全验证。作者认为这种设计模式虽然会略微增加代码复杂度，但收益远大于成本。

内容框架与概述

作者开发了一个定时生成报表的应用程序，需要从数据库读取数据、生成报告、打包上传到SFTP服务器并处理错误响应。受Subversion版本控制系统的启发，作者在开发早期就添加了–dry-run选项。

这个选项的核心价值在于提供了一种无风险的预览机制。作者每天都会使用它来快速验证系统状态是否正常、配置是否正确、各项资源是否可访问，而无需担心产生实际更改。在测试系统行为时，–dry-run能够立即显示决策结果，避免了实际生成报告等耗时操作。

当然，这种模式也有代价。作者需要在代码的各个主要阶段检查dryRun标志，这会在一定程度上污染代码结构。但这种检查通常只停留在调用层面，不需要深入到具体实现逻辑中。作者总结认为，–dry-run特别适合那些由命令触发、会产生状态变更的应用程序，但对于消息驱动等响应式应用则不太适用。关键是要在项目早期就实现这个功能，这样才能在整个开发周期中受益。

核心概念及解读

–dry-run选项：一种命令行参数，让程序只显示将要执行的操作而不实际执行任何更改，为用户提供安全的预览和测试机制。

快速反馈循环：通过–dry-run可以在不产生实际副作用的情况下立即验证系统行为和配置正确性，大幅提高开发和调试效率。

命令式应用：由命令主动触发执行、会产生状态变更的应用程序类型，这类应用特别适合实现–dry-run模式。

原文信息

此摘要卡片由 AI 自动生成