چرا باید از --dry-run استفاده کنی؟
تستخلاصهٔ کاملتر
اگه تا حالا با ابزارهایی مثل Subversion یا دستورات لینوکسی کار کرده باشی، احتمالاً با آپشن --dry-run آشنا هستی. ایدهاش سادهست: دستور رو اجرا میکنی، ولی هیچ تغییری اعمال نمیشه؛ فقط میبینی که اگه واقعاً اجرا بشه، چه اتفاقی میافته.
نویسنده این مقاله چند ماهی مشغول ساختن یه اپلیکیشن گزارشساز بوده. این اپلیکیشن هر روز کاری یه چرخهی کامل داره: داده رو از دیتابیس میخونه، گزارشها رو میسازه، زیپ میکنه، روی سرور SFTP آپلود میکنه، فیدبکها رو دانلود و پارس میکنه، و در نهایت ایمیل اطلاعرسانی میفرسته. فایلها هم بسته به مرحلهای که توش هستن بین پوشههای مختلف جابهجا میشن.
اوایل پروژه، نویسنده تصمیم گرفت یه گزینهی --dry-run به دستور اصلی اضافه کنه. با این فلگ، اپلیکیشن فقط چاپ میکنه که در هر مرحله چی قراره اتفاق بیفته؛ کدوم گزارشها ساخته میشن، کدوم فایلها زیپ و جابهجا میشن، چه چیزی آپلود یا دانلود میشه. ولی هیچکدوم از این کارها در واقعیت انجام نمیشه.
این تصمیم بهظاهر کوچیک، در طول پروژه خیلی پرکاربرد از آب دراومد. نویسنده از --dry-run به عنوان یه چک سریع و بیخطر استفاده میکرد؛ مثلاً قبل از شروع کار روزانه، میفهمید که کانفیگ درسته، همه چیز در دسترسه، و وضعیت اپلیکیشن اونطوری که انتظار داره هست یا نه.
یه مورد کاربردی دیگه هم تست سریع رفتار بود. مثلاً وقتی تاریخ آخرین گزارش موفق رو توی فایل state تغییر میداد، بلافاصله با --dry-run میدید که آیا اون گزارش دوباره تولید میشه یا نه؛ بدون اینکه لازم باشه منتظر بمونه تا گزارش واقعی ساخته بشه. این سرعت فیدبک در حین توسعه خیلی ارزشمنده.
البته این روش یه نقطه ضعف هم داره: باید توی قسمتهای مختلف کد چک کنی که آیا فلگ dryRun فعاله یا نه، و بر اساسش یا عملیات رو انجام بدی یا فقط پرینت کنی. این باعث میشه کد یه کم شلوغتر بشه. ولی این آلودگی عمق زیادی نداره؛ مثلاً کدی که گزارش رو واقعاً میسازه نیازی به چک این فلگ نداره، فقط کدی که تصمیم میگیره اون کد صدا زده بشه یا نه باید این رو بدونه.
نویسنده تأکید میکنه که --dry-run برای همه نوع اپلیکیشنی مناسب نیست. بهترین تناسب با برنامههایی داره که با یه دستور صریح اجرا میشن و تغییراتی ایجاد میکنن. اپلیکیشنهای reactive که منتظر پیامهای خارجی هستن، چندان با این الگو جور نیستن.
نکات کلیدی:
- --dry-run یعنی دستور رو اجرا کنی ولی هیچ تغییری در سیستم ایجاد نشه؛ فقط نشون میده چی قراره بشه
- بهترین زمان اضافه کردنش اوایل پروژهست تا در طول توسعه هم ازش بهره ببری
- برای چک سریع وضعیت سیستم (کانفیگ، دسترسیها، state) خیلی مفیده
- فیدبک سریعتر در تست رفتار اپلیکیشن، بدون اتلاف وقت برای اجرای واقعی
- کد رو کمی شلوغتر میکنه، ولی این شلوغی معمولاً سطحی و محدوده
- برای اپلیکیشنهای command-driven مناسبه، نه reactive/event-driven
