التعامل مع الكود “Legacy Code” القديم والدين التقني “Technical Debt”

مقدمة

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

الكود القديم “Legacy Code”

لنبدأ بتعريف الكود القديم حيث أنه يمثل واحده من أهم العناصر للمشروع والذي يمثل المنطق الخاص بتنفيذ مهام المشروع.

هناك تعريفات مختلفة للكود القديم يشير الكود القديم إلى الكود الذي تم كتابته منذ فترة طويلة أو الكود الذي لا يحتوي على اختبارات ولكن ربما التعريف الأدق هو الكود الذي لا يمكن توضيح نواياه ولا يحتوي على أي دلائل لذلك مثل الوثائق ونحوه.

الدين التقني Technical Debt

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

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

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

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

التعامل مع الدين التقني

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

لذلك ينبغي استيعاب الموقف للبدء بالتعامل مع الديون، دعنا نقوم بإعطاء صورة مفصله:

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

علينا أن نأخذ بالحسبان النقاط التالية للبدء بالتحكم والفعل بدلا من أن نفقد التحكم

لذلك وكأي أمر مبهم، يمكن إتباع الخطوات التالية لتحقيق الغاية النهائية وهي إمكانية التعامل مع النظام القائم والتطوير عليه
سنفصل كل خطوة من هذه الخطوات

التحقيق، والتنقيب عن ما هو متاح

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

كل هذه الأماكن تساعدك عن فهم السياق، ولكن يمكن أن لا يكون أي منها موجود، وبكل الأحوال في حال وجودها فهي عنصر مساعد ينبغي الإستعانه به، وفي حال لا يوجد أي من ذلك، فيمكنك رسم مخطط عام يساعدك في فهم النظام من نطاقه الخارجي.

أهم قاعدة يمكن أن تستعملها هو لا تحاول فهم كل شيء داخل المشروع، فقط حاول أن تفهم الصورة من الخارج.

الإختبار الأولي والتجهيز لبيئة إختبارية

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

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

رسم المحددات والبدء بالتطوير مع دفع الدين التقني

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

هناك إنتصارات سريعة يمكن تحقيقها بمجرد البدء بالتطوير:

هل أترك الكود الموجود على حاله أم أقوم بتغييره؟

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

يمكن أيضا إستخدام التجارب للتحقق من أن ما تقوم به يعمل دون مشاكل مثل مكتبة Github Scientist والتي تساعدك على إبقاء نسختين من الكود لمعرفة النتيجة من التغييرات التي تقوم بها.

من الآن فصاعدا يمكنك دائما بداية ممارسات سليمه من كتابة كود منظم، عمل إختبارات أساسية أو إتباع ال TDD لتغطية الكود بالإختبارات.

أشياء يجب أن تبقيها دائما ضمن الدين التقني الذي تقوم بسداده

بعد أن بدأنا فعلا بالتنفيذ والتصرف على الكود والتطوير هناك أشياء من المهم إعتبارها لضمان إستمرارية مستقبلية

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

أتمنى أن تساعدكم هذه المقالة في التعامل مع الدين التقني والكود القديم، دمتم بود إلى تدونية أخرى

شارك هذا الموضوع: