لگاسی در توسعه اپلیکیشن‌ها — چیست، ریسک‌ها و استراتژی‌های کار

لگاسی در توسعه اپلیکیشن‌ها چیست

لگاسی — کد یا سیستمی که همچنان در محیط تولید کار می‌کند اما دیگر استانداردهای کیفیت مدرن را برآورده نمی‌کند. لگاسی ممکن است به زبان قدیمی (مثلاً Objective-C به جای Swift)، با استفاده از کتابخانه‌های پشتیبانی‌نشده یا الگوهای معماری که مدتهاست ضدالگو شناخته می‌شوند، نوشته شده باشد.

ویژگی کلیدی لگاسی نبود تست است. طبق تعریف Michael Feathers (2004)، کد لگاسی کدی بدون تست است. اگر نمی‌توان رفتار را به طور ایمن تغییر داد، سیستم بدون توجه به سن در وضعیت لگاسی قرار دارد. کد تازه بدون تست واحد — لگاسی روز اول است.

لگاسی لزوماً بد نیست. یک سیستم خوب طراحی شده در Java 8 می‌تواند از کد آشفت در Kotlin با کوروتین قابل اعتمادتر و قابل فهم‌تر باشد. سن کد نشانگر کیفیت نیست — مهم این است که سیستم تا چه حد در برابر تغییرات و گسترش انعطاف‌پذیر است.

چرا کد لگاسی طبیعی است

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

ارزش تجاری لگاسی اغلب دست‌کم گرفته می‌شود. سیستم پایدار کار می‌کند، تراکنش‌ها را پردازش می‌کند، داده‌ها را ذخیره می‌کند — بازنویسی ریسک دارد. طبق Standish Group (2024)، 35% پروژه‌های بازنویسی کامل با شکست مواجه می‌شوند. از نظر اقتصادی، خلاص شدن از لگاسی توجیه ندارد — یادگیری کار با آن منطقی‌تر است.

بهترین استراتژی‌ها — مهاجرت تدریجی، کپسوله‌سازی کد قدیمی پشت رابط‌های جدید و تست خودکار. لگاسی تنها زمانی مشکل می‌شود که دیگر با هزینه قابل پیش‌بینی قابل تغییر نباشد.

نشانه‌های اصلی سیستم لگاسی

نبود تست خودکار — شاخص اصلی. اگر پس از تغییر یک خط کد، برنامه‌نویس نمی‌تواند تست‌ها را اجرا کند و مطمئن شود که چیزی خراب نشده — با لگاسی روبرو هستید. نشانه دیگر: فرآیند استقرار ساعت‌ها طول می‌کشد و نیاز به اقدامات دستی دارد.

مستندات با کد مطابقت ندارد — نشانگر دیگر. نمودارهای معماری قدیمی هستند، نظرات رفتاری را توصیف می‌کنند که تغییر کرده است. زمان یادگیری برای یک برنامه‌نویس جدید بیش از یک ماه — نشانه پیچیدگی بالا و قابلیت نگهداری پایین سیستم.

نشانه‌های اضافی: معماری یکپارچه بدون مرزهای مشخص، تست دستی به عنوان روش اصلی تأیید، pipeline CI طولانی (بیش از 30 دقیقه)، استفاده از کتابخانه‌های بدون نسخه‌های به‌روز و عدم امکان به‌روزرسانی وابستگی‌ها بدون خراب کردن ماژول‌های مجاور.

پدیده «کد شکننده» — تغییر در یک مکان سه جای دیگر را خراب می‌کند. این نتیجه اتصال محکم (tight coupling) است، زمانی که ماژول‌ها بیش از حد درباره یکدیگر می‌دانند. هرچه coupling بالاتر باشد، سیستم سریع‌تر به دسته لگاسی منتقل می‌شود.

ریسک‌های کار با کد قدیمی

کاهش سرعت — ریسک اصلی. افزودن یک ویژگی ساده ساعت‌ها مطالعه کد و روزها تست نیاز دارد. طبق Stripe (2024)، برنامه‌نویسان 33% از زمان خود را صرف غلبه بر بدهی فنی می‌کنند که مستقیماً با وجود ماژول‌های لگاسی در پروژه مرتبط است.

فرار تخصص — نویسندگان کد اصلی از شرکت خارج می‌شوند و مستندات ناقص است. برنامه‌نویسان جدید از دست زدن به ماژول‌های نامفهوم می‌ترسند که منجر به اثر «کد یخ‌زده» می‌شود: ماژول توسعه نمی‌یابد اما به کار ادامه می‌دهد. عامل اتوبوس چنین سیستم‌هایی بحرانی پایین است.

امنیت — کتابخانه‌های قدیمی حاوی آسیب‌پذیری‌های شناخته‌شده هستند. استفاده از OpenSSL 1.0.2 یا نسخه‌های قدیمی Jackson در پروژه‌های Java مسیری مستقیم به حوادث امنیتی است که می‌تواند برای کسب‌وکار هزینه اعتبار و مشتری داشته باشد.

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

استراتژی‌های بازسازی لگاسی

تست‌های مشخصه‌سازی — اولین گام قبل از هر تغییری در کد لگاسی. کد را روی داده‌های ورودی مشخص اجرا کنید و خروجی مورد انتظار را ثبت کنید. این تست‌ها رفتار فعلی را به عنوان مشخصات ثبت می‌کنند. Golden master testing — گونه‌ای که در آن خروجی با یک فایل مرجع مقایسه می‌شود.

تحلیل درز — یافتن نقاطی که می‌توان بدون تغییر رفتار، اتصال را شکست. Michael Feathers چند نوع درز را مشخص می‌کند: preprocessor seam, object seam, link seam. Object seam — رایج‌ترین: جایگزینی شیء واقعی با یک شبیه‌ساز تست از طریق رابط.

Sprout method و Sprout class — تکنیک‌های افزودن کد جدید در کنار کد قدیم، نه درون آن. به جای تغییر متد موجود، یک متد جدید با منطق مورد نیاز ایجاد کنید و آن را از متد قدیمی فراخوانی کنید. این کار خطر خراب شدن کد فعال را به حداقل می‌رساند.

مثال: افزودن لاگ‌گیری در لگاسی

class LegacyPaymentProcessor {
    def process(payment) {
        // 200 خط کد لگاسی که نباید لمس شوند
        logPayment(payment) // sprout method
    }
    def logPayment(payment) {
        // کد جدید اضافه شده در کنار لگاسی
    }
}

مهاجرت به Stack فناوری مدرن

الگوی Strangler Fig — رویکرد توصیه‌شده برای مهاجرت لگاسی. ماژول جدید به صورت موازی ایجاد می‌شود، ترافیک به تدریج از قدیم به جدید منتقل می‌شود. ماژول قدیم زمانی که درخواست دریافت نمی‌کند به طور طبیعی «می‌میرد». الگو ریسک‌ها را به حداقل می‌رساند و در صورت مشکلات امکان بازگشت را فراهم می‌کند.

Branch by Abstraction — تکنیکی که در آن یک انتزاع بر روی پیاده‌سازی قدیم و جدید ایجاد می‌شود. کد مشتری به انتزاع سوئیچ می‌کند، پیاده‌سازی قدیم به تدریج با جدید جایگزین می‌شود. مثال: جایگزینی لایه شبکه از AFNetworking به Alamofire از طریق یک پروتکل واحد NetworkService.

مهاجرت مرحله‌ای — تقسیم انتقال به گام‌های کوچک: کپسوله‌سازی ماژول قدیم → نوشتن تست → ایجاد ماژول جدید → اجرای موازی → حذف ماژول قدیم. هر گام با وضعیت پایدار سیستم به پایان می‌رسد که امکان استقرار تغییرات را در هر لحظه فراهم می‌کند.