Permission و بازبینی کار

در فصل ۱.۲ فهمیدی چرا اصلاً permission وجود دارد: مدل خودش اجرا نمی‌کند، درخواست می‌دهد و برنامه اجرا می‌کند. آن فاصله، جای دروازه است.

و سیستمِ واقعی سه‌سطحی است:

• خواندن — داخل پوشه‌ی کار، معمولاً اجازه نمی‌خواهد. چون خواندن چیزی را عوض نمی‌کند.
• اجرای دستور — اجازه می‌خواهد، جز مجموعه‌ای از دستورهای فقط‌خواندنی که از قبل بی‌خطر شناخته شده‌اند.
• تغییر فایل — همیشه اجازه می‌خواهد.

و یک تفاوت مهم در «بله، دیگر نپرس»: برای دستورها معمولاً دائمی ثبت می‌شود (برای همان دستور در همان پروژه)، ولی برای تغییر فایل تا آخر همان session. یعنی تأییدِ دستور سنگین‌تر از آن است که به نظر می‌رسد.

حالا مهم‌ترین واقعیتِ این فصل، و دلیلی که permission را جدی می‌کند:

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

این تفاوت را با فصل ۱.۴ کنار هم بگذار: آنجا گفتیم فایل قانون «context است، نه پیکربندی اجباری» — یعنی ممکن است رعایت نشود. اما permission برعکس است: یک لایه‌ی واقعی است که بیرون از تصمیم مدل می‌ایستد.

پس اگر می‌خواهی چیزی قطعاً اتفاق نیفتد، نوشتنش در فایل قانون کافی نیست. جایش permission است.

و در لحظه‌ی خودِ پنجره، سه چیز را بخوان:

• چه ابزاری؟ خواندن است یا نوشتن یا اجرای دستور؟
• روی چه چیزی؟ کدام فایل، کدام مسیر. اگر مسیری بیرون پوشه‌ی کارت دیدی، همان‌جا بایست.
• برگشت‌پذیر است؟ نوشتن یک فایل تازه، بله. بازنویسی یا پاک‌کردن، نه.

وقتی می‌خواهد فایلی را عوض کند، معمولاً تغییرات را نشانت می‌دهد — چه خطی حذف می‌شود و چه خطی اضافه.

و اینجا چیزی هست که ارزش دانستن دارد: لازم نیست کد را بلد باشی تا این را بخوانی. سه چیز را نگاه کن:

• چند خط عوض می‌شود؟ اگر گفتی «یک عدد را درست کن» و پنجاه خط عوض می‌شود، چیزی درست نیست.
• چیزی حذف می‌شود؟ خطوط حذف‌شده از اضافه‌شده‌ها مهم‌ترند.
• کدام فایل؟ اگر فایلی است که اصلاً به این کار ربط ندارد، علامت خطر است.

و اگر تغییرات زیاد بود و مطمئن نبودی، بگو «اول توضیح بده هر تغییر چه می‌کند». این همان راستی‌آزماییِ بدون کد است که درس ۴.۵ کاملش می‌کند.

در فصل ۰.۳ گفتیم کد می‌بینی ولی کد نمی‌نویسی. اینجا حداقلی که برای شناختن لازم است — نه نوشتن.

وقتی دستوری می‌بینی، فقط این را تشخیص بده: می‌خواند، یا عوض می‌کند؟

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

و ساده‌ترین راه اگر مطمئن نیستی: بپرس. «این دستور دقیقاً چه می‌کند و اگر اجرا شود چه چیزی عوض می‌شود؟» — پرسیدن ارزان‌تر از برگرداندن است.

گاهی وسط کار می‌گوید باید چیزی نصب شود. این طبیعی است: برای بعضی کارها ابزار جانبی لازم است — مثلاً برای خواندن یک قالب خاص فایل.

به آن چیزها dependency می‌گویند: چیزی که کارِ تو به آن وابسته است.

سه سؤال قبل از «بله»:

• چرا لازم است؟ بپرس. اگر جوابش قانع‌کننده نبود، احتمالاً راه ساده‌تری هم هست.
• از کجا می‌آید؟ از یک منبع شناخته‌شده، یا از آدرسی که کسی در انجمنی گذاشته؟
• کجا نصب می‌شود؟ داخل همین پروژه، یا روی کل سیستمت؟ دومی سنگین‌تر است.

و یک قاعده‌ی عملی: اگر نمی‌فهمی چه چیزی نصب می‌شود، نصبش نکن. بگو «فعلاً نصب نکن، توضیح بده چه چیزی است و چه راه دیگری هست».

حالت‌هایی هست که پنجره‌های اجازه را کم می‌کنند یا کلاً برمی‌دارند. این‌ها وسوسه‌انگیزند چون کار را سریع‌تر می‌کنند. فهرستِ چیزهایی که هیچ‌وقت نباید بدون نگاه رد شوند:

• پاک‌کردن، هر شکلی. برگشت‌ناپذیرترین کارِ ممکن (درس ۵.۱).
• هر کاری بیرون پوشه‌ی کار. مرزِ فصل ۳.۲ برای همین است.
• آوردن چیزی از اینترنت و اجرا کردنش.
• هر چیزی که به رمز، کلید، یا فایل تنظیمات دست بزند (درس ۷.۵).
• تغییر گروهی روی چند فایل. یک خطا در بیست فایل تکرار می‌شود.
• هر کاری روی داده‌ی واقعیِ کار — نه کپی.

و درباره‌ی حالتی که همه‌ی اجازه‌ها را رد می‌کند: توصیه‌ی رسمی صریح است — فقط در محیط‌های جداافتاده مثل یک ماشین مجازی یا container به کارش ببر، جایی که ابزار نتواند آسیبی بزند. و حتی آنجا هم بعضی کارهای فاجعه‌بار (مثل پاک‌کردن ریشه‌ی سیستم) باز هم می‌پرسند، به‌عنوان آخرین ترمز.

ترجمه‌ی عملی‌اش برای تو: روی کامپیوتر کاری‌ات، آن حالت را روشن نکن. اگر کار زیاد کند شده، به‌جایش کار را به زمین بازی ببر (فصل ۰.۹).