تحديث النظام القديم أولاً وبناء سلم التوافق

في المرة الأولى التي فتحت فيها مشروع Java منذ عشرين عامًا، أول ما رأيته لم يكن رائحة الكود، بل رائحة العمر. لا يزال ملف build.xml موجودًا، لكن pom.xml ليس موجودًا؛ بنية الدليل قديمة الطراز، والمدخل الاختباري قديم أيضًا، وحتى “ما إذا كان بإمكانه إعادة بناء منتج قابل للتشغيل” يحتاج إلى إعادة تأكيد. الخطأ الأكثر شيوعًا في هذه المرحلة هو التركيز على الطبقات والأساليب وتجاهل أن ما يعيق التحديث حقًا هو البيئة والمدخل.

أول شيء يجب فعله عند تحديث الأنظمة القديمة هو بناء سلم التوافق. عادة ما تحتوي قاعدة السلم على شيء واحد فقط: جعل النظام القديم يعمل بثبات ضمن القواعد القديمة، ويفضل أن يكون بمثابة كبسولة زمنية. Docker، JDK القديم، أدوات البناء القديمة، أوامر الاختبار القديمة، هذه الأشياء تبدو بدائية، لكنها فعالة جدًا. طالما أن هذه القاعدة ليست في وضع مستقيم، فإن كل تغيير لاحق سوف يختلط بضجيج جديد: سواء كان ذلك هو الكود الذي تم كسره، أو JVM، والصورة، والهندسة المعمارية، والمكونات الإضافية التي تم كسرها، فمن المستحيل معرفة ذلك.

ثم جاء الدور لاختيار الجسر. الهدف من الجسر محدد للغاية: يتم توصيل أحد الطرفين بكود المصدر القديم، والطرف الآخر متصل بالجهاز الجديد. سقط هذا المشروع أخيرًا في Java 8 وGradle 7.6، اللذين ظلا عالقين في قيود كلا الطرفين: لم تعد Java 17 مستعدة لتجميع الكود المصدري لـ Java 1.5، ولا يمكن تشغيل Java 6 في البيئة الأصلية لـ ARM64. إذا كان الجسر خاطئا، فسوف يظل التحديث عالقا في سلسلة الأدوات؛ إذا كان الجسر صحيحًا، فستتمكن الهجرات اللاحقة من المضي قدمًا خطوة بخطوة.

الشيء الأكثر فائدة هنا هو السماح للنموذج الكبير بالقيام بالتنظيم والترجمة. يمكن أن يساعد في ترجمة منطق Ant إلى 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. يمكن لمساعد الطيار توفير الوقت هنا، لكنه يوفر وقت الترجمة، وليس وقت الحكم.

لا يمكن الاستعانة بمصادر خارجية لوقت الحكم. يبدو Gradle 8 أحدث، ويبدو Java 17 أكثر حداثة، كما يبدو القفز مباشرة للأعلى أكثر نظافة، لكن هذه الخيارات قد لا تلبي قيود كود المصدر القديم والاختبارات القديمة في نفس الوقت. الخوف الأكبر في التحديث هو اعتبار ترقيات الأدوات بمثابة تقدم وتشغيل الأوامر بمثابة فهم للنظام. وطالما أن المشروع لم يحقق خط الأساس التشغيلي، فإن الاختبار الأخضر لا يعتبر نصرًا، ويمكن اعتباره فقط أنه لم يصل إلى السطح المكشوف في الوقت الحالي.

النهج الذي أثق به أكثر هو تقسيم المشكلة أولاً إلى أربعة مستويات: ما إذا كان من الممكن تشغيلها، وما إذا كان من الممكن تحريرها، وما إذا كان من الممكن اختبارها، وما إذا كان من الممكن تعديلها. المستوى الأول هو إعادة إنتاج المشهد، والمستوى الثاني هو تحديد الجسر، والمستوى الثالث هو تحديد ما حفظه الاختبار القديم، والمستوى الرابع هو إعادة البناء الحقيقي. يعد مساعد الطيار مفيدًا بشكل خاص في المستويين الأولين. إنها مناسبة للعمل الفعلي الذي يتتبع السجلات وهياكل الدليل، ولتجميع القرائن المجزأة معًا في خريطة قابلة للقراءة. في المستوى الرابع، يجب أن يكون النموذج مسؤولاً فقط عن النقل والمطالبات، ويجب على الأشخاص الاعتماد على الأشخاص في اتخاذ القرارات.

إن النتيجة الأكثر قيمة لتحديث النظام القديم هي تحويل مجموعة من الأشياء التي “يجب أن تنجح” إلى “أشياء تعمل بالفعل ونعرف سبب نجاحها”. وبمجرد إنشاء سلم التوافق هذا، سيكون للتفكيك اللاحق إيقاع وستكون للتغييرات حدود. يشبه مساعد الطيار مساعدًا على الخط الأمامي في هذا الوقت، يحمل مصباحًا يدويًا لإلقاء نظرة على العمر والمدخل والتبعيات. إن ما يحدد الاتجاه حقًا هو الحكم على تاريخ النظام القديم.