تحديث الكود القديم يتطلب علم الآثار أولاً

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

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

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

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

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

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