ابتدا سیستم قدیمی را مدرن کنید و نردبان سازگاری را بسازید

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

اولین کاری که باید هنگام مدرن سازی سیستم های قدیمی انجام داد، ساختن یک نردبان سازگاری است. پایه نردبان معمولاً فقط یک چیز دارد: ایجاد پایداری سیستم قدیمی در چارچوب قوانین قدیمی و ترجیحاً به عنوان کپسول زمان. Docker، JDK قدیمی، ابزارهای ساخت قدیمی، دستورات آزمایشی قدیمی، این چیزها خام به نظر می رسند، اما بسیار مؤثر هستند. تا زمانی که این پایه درست نباشد، هر تغییر بعدی با نویز جدیدی ترکیب می‌شود: این که آیا کد خراب است یا JVM، تصویر، معماری و پلاگین‌ها که خراب شده‌اند، نمی‌توان تشخیص داد.

سپس نوبت به انتخاب پل رسید. هدف پل بسیار مشخص است: یک سر به کد منبع قدیمی و سر دیگر به دستگاه جدید متصل است. این پروژه در نهایت به جاوا 8 و Gradle 7.6 افتاد که فقط به محدودیت‌های هر دو طرف چسبیده بود: جاوا 17 دیگر تمایلی به کامپایل کد منبع جاوا 1.5 ندارد و جاوا 6 نمی‌تواند در محیط اصلی ARM64 اجرا شود. اگر پل اشتباه باشد، مدرنیزاسیون در زنجیره ابزار گیر می کند. اگر پل درست باشد، مهاجرت های بعدی می توانند گام به گام به جلو حرکت کنند.

مفیدترین چیز در اینجا این است که اجازه دهید مدل بزرگ سازماندهی و ترجمه را انجام دهد. این می تواند به ترجمه منطق مورچه به Gradle کمک کند، دایرکتوری ها را به طرح قبلی بازگرداند، و آن پیکربندی های تکراری و مکانیکی را حذف کند. به عنوان مثال، دایرکتوری کد منبع را به صراحت به مسیر قدیمی اشاره کنید و یک کار سفارشی برای اجرای تست main() قدیمی اضافه کنید:

java {
    sourceCompatibility = JavaVersion.VERSION_1_5
    targetCompatibility = JavaVersion.VERSION_1_5
}
sourceSets {
    main {
        java {
            srcDirs = ['java']
        }
    }
}
tasks.register('runLegacyTest', JavaExec) {
    mainClass.set(project.findProperty('mainClass'))
    classpath = sourceSets.main.runtimeClasspath
}

اهمیت این پیکربندی این است که قوانین دنیای قدیم را صریح می کند. دردسرسازترین چیز در پروژه های قدیمی اغلب فقدان توانایی نیست، بلکه این توانایی در عادات پنهان است. تست از طریق ورودی main() اجرا می شود، کد منبع در دایرکتوری قدیمی قرار می گیرد و ساخت با فرض مسیر در دوران Ant نوشته می شود. Copilot می تواند در اینجا در زمان صرفه جویی کند، اما در زمان ترجمه صرفه جویی می کند، نه در زمان قضاوت.

زمان قضاوت را نمی توان برون سپاری کرد. Gradle 8 جدیدتر به نظر می رسد، جاوا 17 مدرن تر به نظر می رسد، و پرش مستقیم به بالا نیز تمیزتر به نظر می رسد، اما این گزینه ها ممکن است محدودیت های کد منبع قدیمی و تست های قدیمی را به طور همزمان برآورده نکنند. بزرگترین ترس در مدرن سازی این است که ارتقاء ابزار را به عنوان پیشرفت و اجرای دستورات را به عنوان درک سیستم تلقی کنیم. تا زمانی که یک پروژه به خط پایه عملیاتی نرسیده باشد، آزمایش سبز یک پیروزی محسوب نمی شود، فقط می توان آن را فعلاً به عنوان عدم برخورد با سطح در معرض دید در نظر گرفت.

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

باارزش‌ترین نتیجه مدرن‌سازی سیستم قدیمی، تبدیل دسته‌ای از چیزهایی است که «باید کار کنند» به «چیزهایی که واقعاً کار می‌کنند و ما می‌دانیم چرا کار می‌کنند». هنگامی که این نردبان سازگاری ایجاد شد، برچیدن بعدی دارای ریتم و تغییرات خواهد بود. خلبان در این زمان مانند یک دستیار در خط مقدم است که چراغ قوه ای در دست دارد تا به سن، ورودی و وابستگی ها نگاه کند. آنچه واقعاً جهت را تعیین می کند، قضاوت تاریخ نظام قدیم است.