از وایب کدینگ تا نرم‌افزار قابل اتکا: فاصله کجاست؟

وایب کدینگ واقعاً چی رو عوض کرد

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

ولی چیزی که تغییر نکرد اینه: نرم‌افزاری که قراره دست آدم‌های واقعی بیفته، به چیزهایی نیاز داره که هیچ‌کدوم در مرحله‌ی دمو دیده نمی‌شن. حالت خطا، داده‌ی بد، کاربر همزمان، تغییر نیازمندی، و کسی که شش ماه بعد باید این کد رو بخونه.

نشانه‌هایی که دمو دارد می‌شکند

معمولاً هفته‌ی دوم است که ماجرا لو می‌ره. این نشانه‌ها رو احتمالاً دیدی:

• هر تغییر کوچک یه چیز دیگه رو می‌شکنه و نمی‌دونی کدوم.
• کد کار می‌کنه ولی نمی‌تونی توضیح بدی چرا.
• برای هر باگ باید کل فایل رو دوباره به مدل بدی، چون خودت نمی‌دونی کجاست.
• دو تا بخش از برنامه دو روش مختلف برای انجام یه کار دارن.
• می‌ترسی چیزی رو حذف کنی، چون مطمئن نیستی استفاده می‌شه یا نه.

هیچ‌کدوم از این‌ها نشونه‌ی بی‌استعدادی نیستن. نشونه‌ی اینن که پروژه از مرحله‌ای که سرعت تنها معیار بود عبور کرده و حالا به ساختار نیاز داره.

تغییر کوچک، اجرای فوری

مهم‌ترین عادتی که همه‌چیز رو عوض می‌کنه اینه: هر تغییر رو کوچک نگه دار، diff رو بخون و قبل از درخواست بعدی رفتار رو اجرا کن. سه تا تغییر پشت سر هم بدون اجرا، یعنی وقتی چیزی شکست نمی‌دونی کدوم یکی مقصره.

خوندن diff غیرقابل مذاکره‌ست. نه برای اینکه به مدل اعتماد نداری، بلکه برای اینکه تنها راه فهمیدن چیزیه که داری تحویل می‌گیری. اگه نتونی diff رو بخونی، عملاً صاحب اون کد نیستی.

از ایجنت بخواه فرض‌ها و فایل‌های درگیر رو روشن کنه، ولی گزارشش رو مدرک نهایی ندون. «تست‌ها پاس شدند» یه ادعاست تا وقتی خودت اجراشون کنی.

شش چیزی که فاصله رو پر می‌کنن

لازم نیست همه‌شون رو از روز اول داشته باشی، ولی قبل از اینکه کاربر واقعی بیاد، همه‌شون باید باشن.

یک: کنترل نسخه، از دقیقه‌ی اول

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

دو: راهی برای اثبات درستی

تست خودکار و typecheck فقط کیفیت رو بالا نمی‌برن؛ به ایجنت هم راه راستی‌آزمایی می‌دن. بدون اون‌ها، ایجنت هیچ سیگنالی برای تشخیص موفقیت نداره و فقط حدس می‌زنه.

سه: مرز بین بخش‌ها

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

چهار: مدیریت خطا و حالت‌های مرزی

دمو مسیر طلایی رو نشون می‌ده. محصول باید بدونه با فایل خالی، شبکه‌ی قطع، ورودی بی‌معنی و کاربری که دو بار روی دکمه می‌زنه چه‌کار کنه. این‌ها رو صریح بخواه، چون به‌صورت پیش‌فرض تولید نمی‌شن.

پنج: امنیت پایه

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

شش: کسی که کد رو می‌فهمه

لازم نیست هر خط رو خودت نوشته باشی، ولی باید بتونی هر خط رو توضیح بدی. این تنها چیزیه که بین «محصول من» و «چیزی که یه ابزار تحویلم داد» فرق می‌ذاره.

چک‌لیست قبل از اولین کاربر واقعی

این فهرست کامل نیست و قرار هم نیست باشه. ولی اگه هر کدوم از این‌ها جوابش «نمی‌دونم» است، همونجا کار داری.

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

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

هیچ‌کدوم از این شش تا به دانش عمیق نیاز ندارن. همه‌شون به این نیاز دارن که یه بار، قبل از اینکه لازم بشن، بهشون فکر کرده باشی.

یک مسیر عملی برای گذر

اگه الان یه دمو داری و می‌خوای محصولش کنی، این ترتیب معمولاً کم‌دردترینه:

1. قبل از هر تغییری، پروژه رو به گیت ببر و یه کامیت از وضعیت فعلی بگیر.
2. مسیر اصلی کاربر رو بنویس — همون چند قدمی که ارزش اصلی رو می‌سازن.
3. برای همون مسیر، یکی دو تست سرتاسری بنویس. نه بیشتر؛ فقط همون.
4. حالا شروع کن به تمیزکردن. هر بار یه تکه، با اجرای تست بعد از هر تکه.
5. وقتی مسیر اصلی پایدار شد، حالت‌های خطا رو یکی‌یکی اضافه کن.

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