دیتا، خودِ اپلیکیشنه
خلاصهٔ کامل‌تر
ماتیاس گنیار تو این پست می‌گه agentic coding (یعنی وقتی یه ایجنت بخش زیادی از کدنویسی رو برات انجام می‌ده) سرعت کارش رو عوض کرده: یه فیچر چند روزه درمیاد و یه طراحی چند ساعته پیاده میشه. بیشتر این کارها رو هم از روی گوشی و با یه محیط کدنویسی ریموت انجام می‌ده، چون هر تغییری یه deploy باهاش فاصله داره. به گفتهٔ خودش هیچ‌کدوم از این‌ها تست‌نشده بیرون نمی‌ره، ولی هزینهٔ یه تصمیم اشتباه چند دقیقه‌ست.
استثنا لایهٔ دیتاست. نویسنده می‌گه هر وقت باید به دیتا دست بزنه متوقف میشه و می‌ره پشت لپ‌تاپ، چون این همون لایه‌ایه که deploy بعدی درستش نمی‌کنه. الگوهایی مثل soft delete، یه migration با down() درست، یا بکاپ دیشب ضربه رو کم می‌کنن، ولی این‌ها فقط تغییرِ کد رو برمی‌گردونن، نه خودِ داده رو. اگه یه migration یه ستون رو خالی کرده باشه، down() همون ستون رو برمی‌گردونه، منتها خالی.
نزدیک‌ترین چیز به دکمهٔ undo برای دیتا، event sourcing ـه، یعنی به‌جای ذخیرهٔ وضعیت فعلی، هر تغییر رو به شکل یه رویداد (مثل OrderPlaced) نگه می‌داری و جدول‌ها رو از همون رویدادها می‌سازی. پکیج event sourcing شرکت Spatie برای لاراول حتی دستور event-sourcing:replay داره. ولی به گفتهٔ نویسنده درِ یک‌طرفه فقط جابه‌جا شده: لاگ فقط append میشه، پس یه رویداد بدطراحی‌شده تا ابد توش می‌مونه و رویدادی که ثبت نکردی قابل replay نیست.
برای توضیح ماجرا سراغ تقسیم‌بندی جف بزوس تو نامهٔ ۲۰۱۵ به سهام‌دارهای آمازون می‌ره: بعضی تصمیم‌ها درِ یک‌طرفه‌ان و برگشت‌ناپذیر، بیشترشون درِ دوطرفه‌ان و قابل برگشت. نگرانی نویسنده اینه که وقتی همه‌چیز دور آدم این‌قدر سریع حرکت می‌کنه، از درِ یک‌طرفه هم با سرعت درِ دوطرفه رد می‌شی. migration، اینکه چی رو و با چه فرمتی ذخیره کنی، ساختار داده، بکاپ و ریکاوری همه تو همین دسته‌ان.
بحث حریم خصوصی و مدت نگه‌داری داده هم همین‌شکلیه: چقدر نگهش داری، کی می‌تونه ببینتش، وقتی کسی اکانتش رو پاک می‌کنه تکلیف بکاپ‌ها چیه. به گفتهٔ نویسنده نوشتن migration هیچ‌وقت بخش کُند ماجرا نبوده؛ فکر کردن به اینکه چه بلایی سر ردیف‌های موجود میاره کُنده. حرف آخرش هم اینه که UI و سرور و اپ رو میشه دوباره ساخت، اون هم سریع‌تر از همیشه، ولی داده‌ای که کاربر بهت داده رو نه.
نکات کلیدی:
- down() تو migration ستون رو برمی‌گردونه، ولی خالی؛ داده‌ای که رفته برنمی‌گرده.
- event sourcing با دستوری مثل event-sourcing:replay تو پکیج Spatie، نزدیک‌ترین چیز به undo واقعی برای لایهٔ دیتاست.
- لاگ append-only خودش یه درِ یک‌طرفهٔ تازه‌ست: رویداد بدطراحی‌شده برای همیشه می‌مونه و با حذف اکانت کاربر هم جور درنمیاد.
- تقسیم‌بندی بزوس در نامهٔ ۲۰۱۵: درِ یک‌طرفه برگشت‌ناپذیره و باید آهسته تصمیم گرفت، درِ دوطرفه قابل برگشته.
- درهای یک‌طرفهٔ یه پروژه: migration، فرمت و ساختار ذخیره‌سازی، بکاپ و ریکاوری.
