کد بخش آسون ماجراست؛ ما نصف کسبوکار رو ریفکتور کردیم
خلاصهٔ کاملتر
نویسنده، سویزک تلر، تجربهٔ تیمش تو Plasmidsaurus رو تعریف میکنه؛ استارتاپی که درآمد سالانهش تو دو سال پنج برابر شده و حالا ۱۰۰ میلیون دلار رو میبینه. مشکل اینجا بود که سیستم صورتحساب برای مقیاس خیلی کوچیکتری ساخته شده بود: یه اسکریپت پایتونی لرزون همهٔ فاکتورها رو صادر میکرد، مشتریها برای هر تغییر به پشتیبانی زنگ میزدن و هر استثنایی که فکرش رو بکنی پذیرفته شده بود.
به گفتهٔ نویسنده، بعد از چند سال این «توپ گِل» اونقدر بدهی فنی و محصولی جمع کرده بود که یه تیم کامل فقط برای زنده نگه داشتنش لازم بود. تیم مالی صدها مشتری رو با اسم میشناخت و کلی قانون کسبوکار وجود داشت که هیچجا نوشته یا کدنویسی نشده بود؛ فقط یه نفر «میدونست باید چی کار کنه». پایان ماه گاهی به شببیداری میکشید.
درس اول مقاله اینه که اول مسئله رو ساده کن، بعد مسئلهٔ ساده رو حل کن. تو چنین سیستمی میشه تا ابد باگهای سطحی رو وصله زد و هیچ پیشرفتی نکرد. سؤال درست اینه: اون یه چیز اصلی که همهچیز رو خراب میکنه چیه؟ جواب تیم، مدل داده بود. کاربرها به موسسهها و آزمایشگاهها وصل بودن و همون ساختار همزمان برای فروش، همکاری بین کاربرها و صورتحساب استفاده میشد.
راهحل، Billing Entity بود: یه مدل دادهٔ جدید که فقط به یه سؤال جواب میده، «این سفارش رو چطوری فاکتور کنیم؟»، مستقل از ساختار سازمانی و همکاریها. نویسنده معتقده مسائل بزرگ و درهم معمولاً همینقدر راهحل ساده دارن: مسئله بزرگ شده چون مدل داده دیگه با دامنه جور نیست و انتزاعها غلطن.
این راهحل رو هم با خیره شدن به کد پیدا نکردن. اولین جلسه با تیم مالی شش ساعت طول کشید و بعدش ماهها با کاربرهای داخلی و مشتریها حرف زدن. نویسنده تأکید میکنه تماشای کارِ آدمها از حرف زدن باهاشون ارزشمندتره: وقتی پرسیدن تیم مالی موقع اعتبارسنجی سفارشهای خرید دنبال چی میگرده، جوابْ فهرست بیپایانی از استثناها بود، ولی وقتی نشستن و پروسه رو تماشا کردن دیدن قاعده سادهست — شمارهها همطولان و پیشوند سهچهار حرفی مشترک دارن. اعتبارسنج همون بعدازظهر آماده شد.
نکتهٔ بعدی اینه که این یه پروژه نیست، یه نقشهٔ راهه. نمیشه کسبوکار در حال پرواز رو متوقف کرد و موتورش رو عوض کرد، پس تیم قدمبهقدم جلو رفت و نرمافزار هیچوقت از کار نیفتاد. ماهها فاکتورگیری تو حالت دوگانه اجرا میشد (اگه Billing Entity بود از اون، وگرنه روش قدیمی) و همین کلی حالت لبهٔ فاجعهبار رو رو کرد.
خروجی نهایی: ابزار جدید برای کاربرها تا خودشون آزمایشگاه بسازن و اطلاعات صورتحساب رو مدیریت کنن، مهاجرت از Quickbooks به Rillet، و بازنویسی اسکریپت فاکتورگیری بهشکل idempotent و قابل اجرای دوباره با یه مجموعه تست کامل. نویسنده میگه حالا کد فاکتورگیری تست بیشتری از خود کد داره، که برای چیزی پر از حالت لبهای نسبت درستیه.
نتیجه؟ فاکتورگیری پایان ماه بهجای یک هفته، دو روز طول کشید و تیم مالی راضیه. کاربرها هم بعد از رونمایی از پنل جدید کلی بازخورد مثبت دادن؛ خیلیهاشون اصلاً نمیدونستن چنین امکاناتی وجود داره. کل ماجرا شش ماه و دستکم شش نفر وقت برد.
نکات کلیدی:
- مشکل اصلی اسکریپت لرزون نبود، مدل دادهٔ نامتناسب با دامنه بود
- راهحل: مدل جدید Billing Entity که فقط جواب میده «چطور فاکتور کنیم»
- تماشای کارِ کاربرها قانون سادهای رو لو داد که هیچکس نتونسته بود توضیح بده
- مهاجرت باید تدریجی باشه؛ نرمافزار باید تو کل مسیر کار کنه
- نتیجه: فاکتورگیری ماهانه از یک هفته به دو روز رسید
