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

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

چرا «همان را با فناوری بهتر بسازیم» ساده نیست؟

Martin Fowler می‌نویسد این طرح ساده به نظر می‌رسد: می‌دانیم سیستم فعلی چه می‌کند، پس همان را با فناوری بهتر می‌سازیم. اما به گفتهٔ او این نقشه «اغلب» شکست خورده است؛ جایگزینی یک سیستم جدی زمان زیادی می‌برد، کاربران در این مدت نمی‌توانند منتظر قابلیت جدید بمانند، تعیین جزئیات رفتار فعلی دشوار است و بخش زیادی از آن رفتار اصلاً مطلوب نیست و ساختنش اتلاف است.

دو دیدگاه که باید کنار هم بخوانید

• Joel Spolsky (۲۰۰۰): بازنویسی از صفر را «بدترین خطای راهبردی» می‌داند و می‌گوید برنامه‌نویسان کد قدیمی را آشفته می‌پندارند چون خواندن کد از نوشتنش سخت‌تر است. نمونه‌های او Netscape، Borland و پروژهٔ Pyramid مایکروسافت‌اند. این یک مقالهٔ نظری قدیمی است، نه پژوهش آماری، و دربارهٔ نرم‌افزارهای دسکتاپ آن دوره است.
• Martin Fowler (۲۰۲۴): رویکرد تدریجی را ترجیح می‌دهد: با افزودن‌های کوچک (اغلب قابلیت جدید) در کنار و جدا از کد قدیمی شروع کنید و رفتار را به‌تدریج منتقل کنید.

هر دو یک نتیجه را تأیید می‌کنند: بازنویسی کامل باید استثنا باشد و دلیل روشن بخواهد، نه واکنش پیش‌فرض به ناراحتی از کد.

سه پرسش پیش از تصمیم

این چارچوب پیشنهاد نویسنده است و از منابع بالا الهام گرفته؛ حکم استاندارد نیست.

1. نتیجهٔ مطلوب دقیقاً چیست؟ فاولر از چهار فعالیت نام می‌برد که اولی «روشن‌کردن نتایج مطلوب» است و می‌گوید اهداف مبهم و متفاوت میان گروه‌ها رایج است. «سریع‌تر شود» یا «مدرن شود» هدف نیست؛ «هر تغییر ظرف چند روز منتشر شود» یا «وابستگی به فلان فناوری حذف شود» قابل‌اندازه‌گیری‌تر است.
2. رفتار فعلی چقدر شناخته‌شده است؟ اگر نمی‌دانید سیستم دقیقاً چه می‌کند، بازنویسی همان نمی‌دانستن را به پروژهٔ جدید می‌برد. نخست باید قابلیت‌ها را فهرست و با داده‌ها یا آزمون مشخص کنید.
3. اگر تغییرات تا پایان بازنویسی متوقف شود چه می‌شود؟ اگر کسب‌وکار نمی‌تواند چند ماه یا بیشتر از قابلیت جدید صرف‌نظر کند، مسیر تدریجی عملی‌تر است؛ همین نکته را فاولر در دلیل شکست طرح ساده آورده است.

نوسازی تدریجی: الگوی Strangler Fig

فاولر این نام را از انجیر خفه‌کنندهٔ جنگل‌های بارانی گرفته که آهسته جای درخت میزبان را می‌گیرد. مایکروسافت در راهنمای معماری آزور الگو را این‌طور توضیح می‌دهد: قابلیت‌ها یکی‌یکی به برنامه‌ها یا سرویس‌های جدید منتقل می‌شوند و یک لایهٔ میانی (façade یا proxy) درخواست‌ها را بین سیستم قدیم و جدید مسیر می‌دهد؛ مشتریان از مهاجرت بی‌خبر می‌مانند و در پایان سیستم قدیمی کنار گذاشته می‌شود. همان صفحه یادآوری می‌کند اگر دو نسخه موازی کار کنند، باید مشخص باشد هر قابلیت در کدام نسخه است و کلاینت‌ها به مکان درست هدایت شوند.

برای شروع، پیشنهاد عملی این است که اولین قطعه را کوچک و کم‌ریسک انتخاب کنید، مثلاً یک گزارش یا یک قابلیت جدید، تا هم روش مسیردهی و هم آزمون مقایسهٔ رفتار تمرین شود. برای ارزیابی اولیهٔ سیستم موجود، ممیزی مهندسی می‌تواند وضعیت کد، آزمون‌ها و استقرار را روشن کند، و اگر در بازسازی کد از ابزارهای هوش مصنوعی استفاده می‌کنید، استفاده از AI برای Refactoring را بخوانید.

پس بازنویسی کامل کی؟

منابع بالا قاعدهٔ «هرگز» یا «همیشه» نمی‌دهند. به‌عنوان نظر نویسنده، بازنویسی وقتی قابل‌دفاع‌تر است که سیستم کوچک و رفتارش با آزمون یا مستندات شناخته‌شده باشد، پلتفرم فعلی واقعاً قابل‌ادامه نباشد (مثلاً پشتیبانی آن تمام شده)، و بتوان نسخهٔ جدید را موازی اجرا و مقایسه کرد. حتی آن‌وقت بهتر است نسخهٔ اولیه فقط بخشی از کار را بردارد.

چک‌لیست پیش از تصمیم

1. هدف را به یک نتیجهٔ قابل‌اندازه‌گیری تبدیل کرده‌ایم.
2. فهرست قابلیت‌ها و جریان‌های مهم، همراه با شاهد (داده یا آزمون)، آماده است.
3. برای هر قطعه، روش مقایسهٔ رفتار قدیم و جدید و برنامهٔ بازگشت داریم.
4. کسب‌وکار قابلیت جدید را در طول مهاجرت چگونه ادامه می‌دهد، مشخص است.
5. مالک تصمیم و ملاک «تمام شد» مشخص است.

اگر می‌خواهید وضعیت سیستم خودتان را با یک تیم مرور کنید، توضیح کوتاهی در صفحهٔ شروع پروژه بفرستید؛ ارسال فرم تعهدی ایجاد نمی‌کند.

منابع و مراجع

• Strangler Fig — Martin Fowler، ۲۲ اوت ۲۰۲۴.
• Things You Should Never Do, Part I — Joel Spolsky (Joel on Software)، ۶ آوریل ۲۰۰۰.
• Strangler Fig pattern — Microsoft Learn — Azure Architecture Center.