هذا هو الجزء الثالث من سلسلة (التعامل بفاعلية مع الكود الموروث). يمكنك الاطلاع على الجزء الأول من هنا، والثاني من هنا.

نحاول في هذه السلسلة تلخيص كتاب “التعامل بفعالية مع الكود الموروث”. نحن الآن في الوحدة الثانية التي تتحدث عن  working with feedback بمعنى الإشارات والدلالات التي يجب أن ننتبه لها عندما نقوم بالتعديل على الكود لتساعدنا على فهم فيما إذا كنا نمشي في الطريق الصحيح أم لا.

تختلف أساليب التعديل على أي نظام برمجي بإختلاف المبرمج, بشكل عام هناك نوعين:  

• Edit and pray
• Cover and modify

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

Edit and pray

عند البدء بتغيير كود ما,  تبدأ بقراءته ومحاولة فهمه , ثم تبدأ بإجراء التغيير, وعند الانتهاء تختبر الميزات الجديدة التي قمت بإضافتها، تتأكد أن البرنامج مازال يعمل. تتوسع تقوم بتجريب أشياء أخرى ضمن البرنامج تتأكد أنه مازال يعمل كما هو متوقع منه. إذا كان هذا أُسلوبك كمبرمج, يجب أن تعلم أنك تعمل بإسلوب Edit and pray.

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

لا أعتقد أن أحدا من يختار لإجراء عمل جراحي معقد, طبيب جراح يعمل بسكين المطبخ، فقط لان هذا الجراح سيجري العملية بحذر شديد. تغيير الكود بطريقة إحترافية يشبه لحد ما إجراء عملية جراحية , يتطلب الأمر كلٌ من المهارات والأدوات الكافية.

العمل بحذر جيد ولكن غير كافي أبدا في حال غياب الأدوات و التقنيات الصحيحة

 

Cover and modify

أسلوب التعديل على الكود هنا مختلف تماما. الفكرة الأساسية هنا هي تغطية الكود شبكة أمان safety net قبل التعديل عليه.

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

في الحالة المثلى في حياة المبرمج، يكون ال code مغطى بعدد كافي من ال tests التي تساعد على التأكد من أن التغييرات الجديدة جيدة و تؤدي الهدف منها أم لا.

الهدف من وجود هذه ال Tests هو إعطاء feedback فيما إذا كانت التغييرات الجديدة تجعل نظامنا البرمجي يعمل كما هو متوقع أم أنها تعقد الكود و تجعله مليء بال Bugs.

Tests لكشف التغييرات في الكود

هناك أنواع عديدة من ال tests تختلف باختلاف الهدف من كتابتها:

Regression test

ال Regression tests يكتب حتى يتم التأكد من أن البرنامج يعمل بالطريقة المتوقعة .يعتبر هذا النوع من ال tests مثل وجود Software Vise. ال Vise هي نفس الأداة في الصورة التالية.

تبقي هذه ال Software vise الكود ثابت لا يتغير و تجعلنا نتأكد من أن التغييرات لم تؤثر في عمل البرنامج.

هذا النوع من ال tests فعال ولكنه غالبا ما يتم على مستوى واجهة المُستخدم user interface. كما أن نتائجه تكون عامة مثل أن “الكود لم يعد يعمل بالطريقة المتوقعة” دون تفاصيل دقيقة عن السبب الذي أدى إلى فشل ال test أو الجزء من الكود المسؤول عن هذا الفشل.

تخيل أن الكود الذي نريد تعديله كبير و معقد, في هذه الحالة نحن بحاجة لمعلومات أدق في حالة فشل ال test، ما يساعد في تقليل احتمالات أماكن الخطأ في الكود. في هذه الحالة يجب أن نستخدم نوع أخر من ال Testing هو ال Unit Tests.

Unit Tests

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

ال Unit tests هي واحدة من أهم مكونات العمل مع الكود الموروث

الخلاصة

• ال tests بكل أنواعها مهمة لأنها تعطي feedback عن حالة الكود عند كل تعديل.
• وجود ال Regression test ضروري و مهم و لكن وجود unit tests صغيرة ومسؤولة عن أجزاء محددة من الكود أكثر أهمية بسبب وضوح ال feedback التي يعطينا إياها عن سبب المشكلة، ما يوفر علينا وقت لإصلاح المشاكل بأمان أكثر.

المصدر: التعامل بفعالية مع الكود الموروث 3-دلالات عند تغيير الكود