أثناء تحديث النظام القديم، يقوم مساعد الطيار أولاً بتنظيم الأدلة

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

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

docker run --rm -v "$PWD":/src -w /src legacy-jdk8 \
  sh -lc './gradlew test 2>&1 | tee logs/baseline.log'

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

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

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

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