درهای دوطرفه پشت سرت قفل میشن
خلاصهٔ کاملتر
نویسنده سراغ جملهای میره که تو خیلی از جلسههای فنی شنیده میشه: «نگران نباش، این یه تصمیم دوطرفهست و هر وقت خواستیم برش میگردونیم.» مثالش انتخاب یه سرویس feature flag هست؛ روز اول هم واقعاً همینطوره و تو ADR مینویسن ریسکش پایینه و برگشتش نهایتاً چند روز کار داره. حرف اصلی مقاله اینه که اون جمله یه ویژگی ثابت سیستم نیست، فقط توصیف همون روزه.
چیزی که عوض میشه، خود کد نیست. به گفتهٔ نویسنده بعد از مدتی تیم محصول از فلگها برای gate کردن قابلیتها استفاده میکنه، تیم دیتا ساینس باهاشون A/B تست میگیره، سیستم انتشار داخلی بهشون هوک میشه و داشبورد آنالیتیکس مستقیم از API همون سرویس وضعیت میخونه. عوض کردنش تو کد هنوز سادهست، ولی عوض کردنش تو کل سیستم دیگه اصلاً ساده نیست.
جالبترین بخش استدلال همینجاست: یه تصمیم برگشتپذیر در واقع یه جور اختیار یا option به حساب میاد که داری نگهش میداری، یعنی حق سوییچ کردن در آینده بدون اجبار. ولی تو دنیای مالی قیمت اعمال اون اختیار تو قرارداد قفله و اینجا نیست. نویسنده میگه قیمت خروج فنی رو نحوهٔ استفادهٔ خودت از ابزار تعیین میکنه و این عدد فقط یه جهت داره: بالا. اسمش رو میذاره بدهی برگشتپذیری؛ درست مثل بدهی فنی بهرهش رو نمیبینی تا روزی که صورتحساب بیاد.
نویسنده میگه این الگو همهجا تکرار میشه: سرویس ابری تا وقتی پرتابله که سراغ صف مدیریتشده و رانتایم سرورلس اختصاصی نری، CI/CD تا وقتی فقط یه اسکریپت بیلد صدا میزنی، و observability تا وقتی کوهی از داشبورد و alert به زبونی که جای دیگه اجرا نمیشه ننوشتی. راهکار پیشنهادیش هم اینه که تو ADR صریح بنویسی چه فرضی این تصمیم رو برگشتپذیر نگه میداره، یه عدد تقریبی برای هزینهٔ خروج بذاری و هر چند وقت بهروزش کنی، خروج رو واقعاً تست کنی، و اختیارهای کمارزش رو عمداً بذاری منقضی بشن.
نکات کلیدی:
- «بعداً میتونیم مهاجرت کنیم» یه ویژگی دائمی سیستم نیست و باید فعالانه نگهش داری
- قیمت خروج از یه ابزار با هر یکپارچگی جدید بالاتر میره و هیچوقت پایین نمیاد
- سادگی تعویض تو کد فریبدهندهست؛ چیزی که سخت میشه، تعویض تو کل سیستمه
- تو ADR فرضهایی که برگشتپذیری بهشون وابستهست رو صریح بنویس
- نگهداری optionality هزینه داره؛ گاهی بهترین کار اینه که آگاهانه ولش کنی
