آنچه بازنویسی یک پروژه‌ی ۴۰ ساله به من درباره‌ی توسعه‌ی نرم‌افزار آموخت 🧓💻⚙️

«وظیفه‌ی شما این است که این سیستم را بازنویسی کنید. تمام عملیات ما روی آن اجرا می‌شود.
اوه، و این سیستم با APL نوشته شده.»

با این جمله، سفر من برای بازنویسی یک سیستم legacy آغاز شد. برای کسانی که با APL آشنا نیستند: این زبان برنامه‌نویسی مربوط به دهه‌ی ۱۹۶۰ است و به‌خاطر نشانه‌گذاری ریاضی خاص و توانایی‌های قدرتمند در array manipulation شناخته می‌شود. پیدا کردن توسعه‌دهنده‌ای که امروز APL بداند تقریباً به سختی پیدا کردن یک floppy disk drive در یک کامپیوتر مدرن است. 🥲💾

این سیستم طی چهار دهه رشد کرده بود. ابتدا یک ابزار ساده‌ی مدیریت موجودی بود، اما کم‌کم به یک سیستم ERP جامع تبدیل شد.
بیش از 460+ جدول دیتابیس. بی‌شمار Business rule در دل کد.Integrationهای پیچیده در هر بخش از فرآیند کسب‌وکار.
این سیستم ستون فقرات یک عملیات تولیدی بود که بیش از ۱۰ میلیون دلار درآمد سالانه ایجاد می‌کرد. 🏭💰

ماموریت ما واضح اما ترسناک بود:
مدرن‌سازی این سیستم با استفاده از dotNET,PostgreSQL, و React. ⚡️

اما یک نکته‌ی حیاتی وجود داشت:
کسب‌وکار باید بدون کوچک‌ترین وقفه ادامه پیدا می‌کرد.
بدون downtime.
بدون data loss.
بدون اختلال در عملیات روزانه. ⛔️🕒

این فقط یک چالش فنی نبود. یک درس بزرگ بود درباره‌ی مدیریت پیچیدگی، فهم فرآیندهای legacy، و هدایت تعاملات سازمانی.

این داستان و درس‌های آموخته‌شده‌ی آن است.

وضعیت اولیه: درک Legacy 🏛🧠

اولین چالش این بود که بفهمیم این سیستم عظیم چطور کار می‌کند. این codebase طی ۴۰ سال به‌صورت ارگانیک رشد کرده بود و تنها توسط یک تیم توسعه‌ی ثابت نگهداری می‌شد. اعضای این تیم حالا در دهه‌ی ۶۰ زندگی بودند و قصد بازنشستگی داشتند.

وقتی وارد اولین بازبینی کد شدیم، انگار یک کپسول زمان باز کرده باشیم.
سینتکس بسیار فشرده‌ی APL باعث می‌شد منطق تجاری پیچیده فقط در چند خط نوشته شود.
زیبا، اگر می‌توانستید آن را بخوانید.
وحشتناک، اگر نمی‌توانستید.
و اکثر ما نمی‌توانستیم. 😅📜

تیم اصلی در مرحله‌ی انتقال دانش، بی‌قیمت بود. آن‌ها تمام نکته‌ها، edge caseها، و business ruleهایی را که طی دهه‌ها اضافه شده بود، از حفظ بودند. اما تنها بخش محدودی از این دانش را می‌توان از طریق گفتگو منتقل کرد. Documentation کم بود. هر آنچه وجود داشت منسوخ شده بود.
مستندات واقعی در ذهن توسعه‌دهندگان اصلی بود.

ما هفته‌ها صرف map کردن کارکردهای سیستم کردیم:

• فرآیند اصلی تولید در بیش از 50+ جدول با وابستگی‌های پیچیده پخش شده بود

• مدیریت موجودی تقریباً به همه‌ی بخش‌های دیگر سیستم وصل شده بود

• ابزارهای گزارش‌گیری custom طی دهه‌ها ساخته شده بودند تا نیازهای خاص را برآورده کنند

• ءIntegration با سیستم‌های خارجی از طریق یک هزارتوی stored procedureها انجام می‌شد

• جدول‌هایی که با ساختارهای ساده شروع شده بودند اکنون شامل صدها ستون بودند؛ برخی ستون‌ها دیگر استفاده نمی‌شدند، اما حذفشان ممکن نبود چون شاید یک گزارش نامعلوم هنوز به آن‌ها وابسته باشد

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

ما به یک رویکرد سیستماتیک برای فهمیدن این «هیولا» نیاز داشتیم.
شروع کردیم به map کردن business processها و پیاده‌سازی فنی متناظر آن‌ها.
این کار به ما کمک کرد domainهای اصلی را شناسایی کنیم؛ domainهایی که بعدها معماری ماژولار سیستم جدید را شکل دادند.

مهم‌تر از آن، به ما کمک کرد مقیاس واقعی کاری که در پیش داشتیم را درک کنیم. 🧩📘