مستندکردن، تحویل و مالکیت

هر اتوماسیون یک فایل توضیح لازم دارد. کوتاه — نیم صفحه کافی است — ولی باید این شش بند را داشته باشد:

1. چه می‌کند، در یک جمله. نه چطور؛ چه.
2. چه چیزی لازم دارد: ورودی از کجا، چه کلیدهایی، چه دسترسی‌هایی.
3. چطور اجرا می‌شود: دقیقاً چه دستوری، در چه پوشه‌ای.
4. خروجی کجا می‌رود.
5. وقتی خراب شد، اول کجا را نگاه کن. این بند را همه جا می‌ندازند و بیشترین ارزش را دارد.
6. و چه چیزی را نمی‌کند — مرزهایش. این جلوی استفاده‌ی اشتباه را می‌گیرد.

و کجا بنشیند؟ در همان پوشه، با نامی که خودش را معرفی کند (فصل ۶.۲.۱). فایل توضیحی که جای دیگری است، خوانده نمی‌شود.

به‌خاطر بسپار فایل توضیح را برای کسی بنویس که هیچ‌چیز از این کار نمی‌داند و تو هم در دسترس نیستی. اگر جایی نوشتی «مثل همیشه» یا «فایل مربوطه»، همان‌جا فرض کرده‌ای خواننده چیزی می‌داند که نمی‌داند — و یکی از آن خواننده‌ها، خودتِ شش ماه بعد است.

فاصله‌ی این دو بیشتر از آن است که به نظر می‌رسد، چون روی دستگاه تو چیزهایی هست که فراموش کرده‌ای وجود دارند. چهار مانعِ همیشگی:

• مسیرهای مطلق. /Users/من/... روی دستگاه او وجود ندارد. راه‌حل: مسیر نسبی (فصل ۷.۱.۳).
• کلیدها. او کلیدهای تو را ندارد و نباید هم داشته باشد. راه‌حل: فایل .env.example و اینکه کلید خودش را بسازد (فصل ۷.۵.۳).
• چیزهای نصب‌شده. ابزارهایی که تو ماه‌ها پیش نصب کرده‌ای و یادت رفته. راه‌حل: فهرست کن — یا Docker (فصل ۷.۳.۳).
• و دانشِ نانوشته. «اول باید فایل را از فلان‌جا دانلود کنی» — چیزی که برای تو بدیهی است و در هیچ فایلی نیست. این سخت‌ترینشان است، چون نمی‌دانی که می‌دانی‌اش.

و تنها آزمونِ معتبر یکی است: یک نفر دیگر، بدون کمکِ تو، اجرایش کند. نه اینکه بگویی «به نظرت واضح است؟» — که همیشه جوابش بله است. بگذار انجام دهد و ساکت بمان. هر جا گیر کرد، یک بندِ گم‌شده در فایل توضیح است.

و اگر کسی نیست: خودت روی یک پوشه‌ی تازه اجرایش کن، فقط با آنچه در فایل توضیح نوشته‌ای. تقریباً همان‌قدر افشاگر است.

یک واقعیت که بهتر است از اول بدانی: اتوماسیون یک شیء نیست که بسازی و تمام شود؛ چیزی است که زنده نگهش می‌داری.

و پوسیدنش تدریجی است، نه ناگهانی — همان چهار موردِ فصل ۸.۷.۲: منبع عوض می‌شود، کلید منقضی می‌شود، ابزار به‌روز می‌شود، فرض‌ها کهنه می‌شوند.

پس در هزینه‌ی ساختن، هزینه‌ی نگهداری را هم حساب کن — همان چیزی که فصل ۲.۱.۳ گفت و اینجا واقعی می‌شود. یک اتوماسیون که ماهی نیم ساعت نگهداری می‌خواهد، باید ماهی بیش از نیم ساعت صرفه‌جویی کند، وگرنه ضرر است.

و یک تصمیم که کسی جدی‌اش نمی‌گیرد: گاهی جوابِ درست، خاموش‌کردن است. اگر اتوماسیونی دیگر به کارت نمی‌آید، حذفش کن — نه اینکه بگذاری اجرا شود و نادیده‌اش بگیری. اتوماسیونِ نادیده‌گرفته‌شده هم منابع مصرف می‌کند و هم فضای ذهنی، و از همه بدتر: اعلان‌هایش را یاد می‌گیری نادیده بگیری — و همین عادت، اعلانِ مهمِ بعدی را هم قربانی می‌کند.

و سؤال آخرِ این ماژول، که فنی نیست:

اگر چیزی ساخته‌ای که دیگران به آن تکیه می‌کنند، یک مسئولیت ساخته‌ای. و اگر فردا این کار را ترک کنی یا مرخصی بروی، آن مسئولیت جایی باید برود.

سه سؤال که باید جواب داشته باشند — و اگر ندارند، تو تنها نقطه‌ی شکستِ آن سیستمی:

1. چه کسی می‌داند این وجود دارد؟ اگر فقط تو، پس وقتی نباشی کسی حتی نمی‌فهمد چه چیزی خراب شده — فقط می‌بیند گزارشی نمی‌آید.
2. چه کسی می‌تواند خاموشش کند؟ این از تعمیرکردن مهم‌تر است. اگر اتوماسیونی شروع کند به فرستادنِ چیزهای غلط و هیچ‌کس نداند چطور متوقفش کند، از نبودنش بدتر است.
3. و چه کسی تعمیرش می‌کند؟ جوابِ صادقانه ممکن است «هیچ‌کس» باشد — و آن‌وقت باید بدانی که این سیستم تاریخ انقضا دارد.

به‌خاطر بسپار سپردنِ کاری به یک اتوماسیون یعنی برداشتنِ آن از دوشِ آدم‌ها — و اگر مالکش مشخص نباشد، آن کار به دوشِ هیچ‌کس نیست. این تا روزی که کار می‌کند مشکلی نیست، و روزی که نکند، تازه معلوم می‌شود کسی حواسش نبوده.

و همین‌جا جمع‌بندیِ کلِ M8: یک اتوماسیون تا وقتی خودکار اجرا نشود و کسِ دیگری نتواند استفاده‌اش کند، تمام نیست. ساختنش شاید نصفِ کار باشد؛ نصفِ دیگر همین سه فصل آخر است.