لا يوجد مُبرمج مهما كان خبيرًا لا يخشى التعامل مع الكود الموروث Legacy Code. لكن هناك عدد من النصائح التي يمكن اتّباعها للتعامل مع الكود الموروث بهدوء واحترافية، سنتعرّف عليها من خلال سلسلة المقالات هذه.

لمصطلح الكود الموروث legacy code أكثر من تعريف وردّة فعل واحدة من أي مبرمج بمجرد ذكر الكلمة أمامه:

يمكننا أن نُعرّفه على أنه الكود المكتوب من قبل مبرمج أو مجموعة مبرمجين، و فجأة  تنضم أنت إلى الفريق أو تكون الشخص الوحيد الذي تُرِكَ في الساحة ليفهمه ويصلحه ويطوره، وللأسف يكون الكود غير قابل للفهم أو الإصلاح.

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

أي بإختصار:

 مصطلح ال legacy code يشير إلى الكود الصعب التغيير، صعب الفهم.

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

في سلسلة العمل مع الكود الموروث سأقوم بتلخيص ما قرأت في كتاب Working effectively with legacy code للرائع Michael C. Feathers .

هدفي من هذه السلسلة أن نتعرف معًا على زاوية جديدة في عالم البرمجة،  وتقديم مفاهيم جديدة لم ندرسها في الجامعات و المعاهد، بل هي خلاصة تجارب كبار المبرمجين على فترات طويلة.

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

ال Tests هم أصدقاؤك الحقيقيون

كما أشرنا مسبقا إلى أن مصطلح ال legacy code يدل على الكود الصعب التغيير وصعب الفهم. يقول الكاتب أنه وحسب خبرته في مساعدة الكثير من الفرق على تجاوز مشاكل متعلقة بال legacy code، إن التعريف الصحيح بالنسبة له هو أن ال legacy code هو الكود بدون Tests.

كما يمكننا القول بأن الكود بدون Tests هو كود سيء، لا يهم مدى إتقان كتابة الكود، ولا يهم كم أحسنت استخدام مفاهيم البرمجة غرضية التوجّه Object-oriented.

​البرمجيات التي يصعب التعديل عليها حسب تغير المتطلبات هي برمجيات ضعيفة التصميم. يمكننا أن نتفق على هذه النقطة في حال كنت من المبرمجين الذين يقولون أن السبب في مشاكل الكود هو كثرة تغير المتطلبات من قبل الزبون.

مهمتنا كمبرمجين أن نقوم بتصميم برمجيات يمكنها ان تتأقلم مع أي تغيير بسهولة و بسرعة نسبية قدر المستطاع. وحتى يكون من السهل التعديل على الكود يجب حتما أن يتم دعمه دائما و أبدا بال tests.

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

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

الخلاصة :

كتابة كود نظيف شئ جيد ولكن ليس كاف. ال Tests هم أصدقاؤك الحقيقيون.

المصدر: التعامل بفاعلية مع الكود الموروث [برمجة]