مدرن کردن کدهای قدیمی ابتدا به باستان شناسی نیاز دارد

سخت ترین چیز در مورد کدهای قدیمی هرگز نحو قدیمی نیست، بلکه زمان های قدیمی است. یک پروژه با build.xml، JDK قدیمی، چارچوب آزمایشی قدیمی و روش‌های بسته‌بندی قدیمی پر شده است. در ظاهر، مانند چندین انبوه فایل به نظر می رسد، اما در واقع لایه هایی از فرضیات تاریخی است که روی هم چیده شده اند. خود کد فقط بیرونی ترین لایه است. آنچه واقعاً تحویل را مسدود می‌کند این است که آیا این مفروضات هنوز وجود دارند، آیا می‌توان آنها را بازتولید کرد و آیا رفتار قدیمی پس از تغییرات از بین می‌رود.

به همین دلیل است که «باستان شناسی» مقدم بر «تحول» است. ابتدا به فایل ساخت، سپس وابستگی ها، سپس محیط در حال اجرا و سپس تست ها نگاه کنید. ترتیب را نمی توان برگرداند. build.xml هنوز وجود دارد، اما pom.xml وجود ندارد. چنین سیگنال هایی برای نشان دادن اینکه پروژه در عصر مورچه ها زندگی می کند کافی است. این که آیا کد می‌تواند کامپایل شود، آیا آزمایش‌ها می‌توانند اجرا شوند یا نه، و اینکه آیا محصول می‌تواند دوباره ساخته شود، اولین شواهد هستند. مفیدترین بخش مدل در اینجا نوشتن فوری کد جدید برای کد قدیمی نیست، بلکه شناسایی این شواهد از روی انبوهی از قطعات است.

محیط نیز باید ابتدا سنجاق شود. کدهای قدیمی اغلب با JVM های قدیمی، کانتینرهای قدیمی و فرضیات قدیمی معماری همراه هستند. آن را مستقیماً روی ماشین‌های امروزی پرتاب کنید، به‌ویژه در محیط‌های معماری متقابل، و در هنگام بروز مشکلات به راحتی می‌توان آن را با نویز جدید ترکیب کرد: آیا کد ذاتاً خراب است یا شبیه‌سازی، آینه‌سازی و زنجیره‌های ابزار است که باعث ایجاد مشکل می‌شوند؟ اگر در این مرحله حتی نتوانید به “همان کد را می توان به طور پایدار در یک محیط بازتولید کرد” دست یابید، تمام اقدامات مدرن سازی بعدی فقط حدس و گمان خواهند بود.

ارزش هوش مصنوعی در این مرحله مشخص است: می تواند به ترجمه در سطح کاراکتر و ساختار کمک کند. تبدیل Ant به Gradle، تبدیل اسکریپت‌های ساخت قدیمی به فرمی که اکنون قابل نگهداری است، انتقال دسته‌ای از XML تکراری و boilerplate به یک مکان واضح‌تر، همه مواردی هستند که کاندیدهای خوبی برای خروج به مدل‌ها هستند. این سریع است، مایل به تلاش دوباره و دوباره، و نه خیلی بی اهمیت است. اما برای داوری مناسب نیست. کدام اخطارها را می‌توان ابتدا نگه داشت، کدام آزمون‌ها واقعاً دروغ می‌گویند، کدام ماژول‌ها باید ابتدا قطع شوند، و کدام کلاس‌ها فقط باید بسته‌بندی و تطبیق داده شوند. در نهایت، هنوز باید توسط مردم تصمیم گیری شود.

آزمایش ساده ترین راه برای فریب دادن مردم است. گذراندن آزمایشات در پروژه قدیمی به معنای درک سیستم نیست، بلکه ممکن است به این معنی باشد که برخی از رفتارهای قدیمی فقط در محیط فعلی پیچیده شده اند. این احساس “همه سبز” خطرناک است زیرا اغلب یک مشکل بزرگتر را پنهان می کند: آنچه آزمایش تأیید می کند جزئیات اجرای یک دوره خاص است، نه معنای تجاری که اکنون باید حفظ شود. اگر واقعاً می خواهید اصلاح کنید، اولین کاری که باید انجام دهید این است که این تست ها را از “حس تزیینی امنیت” خارج کنید و دوباره درباره آنچه محافظت می کنند قضاوت کنید.

بنابراین، پایدارترین راه برای این نوع پروژه ها معمولاً بازنویسی یکباره آن نیست، بلکه ابتدا یک کپسول زمانی برای اصلاح محیط قدیمی، رفتارهای قدیمی و وابستگی های قدیمی ایجاد می کند و سپس آن را در امتداد باریک ترین شکاف ها حذف می کند. ابتدا سیستم را قابل تکرار کنید، سپس کارهای تکراری را برای ترجمه به هوش مصنوعی بسپارید و سپس لایه به لایه مرزها را جدا کنید. اگر نظم از نظم خارج شود، مدل پروژه قدیمی را سرعت می بخشد و آن را به هرج و مرج عمیق تر می کشاند. اگر ترتیب درست باشد، مدل مانند یک دستیار باستان شناسی واقعاً مفید خواهد بود که مسئول جابجایی آجرها، تمیز کردن گرد و غبار، و مقایسه شواهد، رهایی مردم از کارهای کثیف و واگذاری قضاوت در دستان آنها است.