مقدمة
في عالم التطوير، نواجه غالبًا تحديات مع الكود القديم والدين التقني. بالذات عند الإنضمام إلى شركة أو مؤسسة كانت تعمل لفترات طويلة، أو تعاقب على تطوير الأنظمة والبرمجيات مطورين مختلفين، ويحدث ذلك نتيجة عن إختيار الحلول السريعة بدلا من إتباع أفضل الممارسات، ولكن هذا لا يعني أبدا أن الخيارات كانت متاحة لإتباع أفضل الممارسات في ذلك الوقت، سنعود لهذه النقطة لاحقا. في حال تواجه مثل هذا النوع من التحدي، أو أنك تتوقع أن تواجه هذا الأمر، فهذا المقال يخصك.
الكود القديم “Legacy Code”
لنبدأ بتعريف الكود القديم حيث أنه يمثل واحده من أهم العناصر للمشروع والذي يمثل المنطق الخاص بتنفيذ مهام المشروع.
هناك تعريفات مختلفة للكود القديم يشير الكود القديم إلى الكود الذي تم كتابته منذ فترة طويلة أو الكود الذي لا يحتوي على اختبارات ولكن ربما التعريف الأدق هو الكود الذي لا يمكن توضيح نواياه ولا يحتوي على أي دلائل لذلك مثل الوثائق ونحوه.
الدين التقني Technical Debt
هو تشبيه أطلقه وارد كنغهام وهو أحد مؤلفي ميثاق ال Agile ، حيث أشار بأن بعض المشاكل المتعلقة بالبرمجة تشبه الديون المالية. حيث أنه يمكن الإقتراض طالما أنك تستطيع سداد الديون. وهذا التشبيه يأتي بأن بعض المشاكل تأتي نتيجة عن اختيار الحلول السريعة بدلاً من اتباع أفضل الممارسات، هذه الحلول السريعة بكل تأكيد لا تكون مقصوده أو تأتي في ظروف معينه ولكنها تشبه الديون التي يجب تسديدها.
وأضيف إلى هذا التعريف بأن الأمر لا يقتصر فقط على البرمجة وإنما يشمل البيئة التي تحوي هذه البرمجيات، فنسخ الأجهزة التي تعمل عليها هذه البرمجيات وقواعد البيانات وكافة أجزاء البيئة تكون من ضمن الدين التقني الذي يتجوب علينا سداده وإلى سيؤدي بنا إلى الإفلاس.
بكل تأكيد الكثير من التقنين والفنين الذي يوكل إليهم هذا الدين، فإن أفضل جواب “لنبني الشيء من البداية” وذلك قد يعد الطريق الأسهل نظرا لأنك ستستخدم ممارساتك وأدواتك التي تعرفها. صحيح أن هذا الأمر ينطبق في بعض الحالات، وقد يكون الهدم والبناء من جديد أقل تكلفة من العمل على ما هو قائم.
من ناحية أخرى قد يكون هذا مرهق ومكلف وقد يكبد المؤسسة أو الشركة خسائر نتيجة لإعادة بناء الأنظمة، وقد يكون مكلف لك أيضا فعل ذلك. فربما يكون النظام الذي تتعامل به يحقق غايته وكل ما عليك هو تحقيق بعض العناصر لضمان الإستمرار.
التعامل مع الدين التقني
لقد واجهت هذا التحدي مرارا، حيث تأتي هذه التجربة نتيجة لتوليك منصب جديد لمؤسسة أو شركة، أو أنه أوكل إليك نظام قديم للتعامل معه، وقد واجهت هذا الأمر في أكثر من مناسبة.
لذلك ينبغي استيعاب الموقف للبدء بالتعامل مع الديون، دعنا نقوم بإعطاء صورة مفصله:
- أنت لا تعرف أي شيء عن البرمجيات الموجوده
- يوجد الكثير من الأشياء المبهمة والغير مفهومه داخل هذا الكود
- قد لا يكون هناك توثيق لهذه البرمجيات ولا يوجد أيضا وحدات إختبارية
وللوهلة الأولى يبدو الأمر كفوضى، وكأنك في مكان ولا تملك البوصلة التي تدلك على الإتجاه، ولكن التعامل مع الأمر بطريقة هندسيه وبنظام وبمراحل سيؤدي حتما إلى النتيجة.
علينا أن نأخذ بالحسبان النقاط التالية للبدء بالتحكم والفعل بدلا من أن نفقد التحكم
- لا تجزع من المسألة وتشعر بأنك لا تملك التحكم ولا يمكننك فعل شيء هنا
- لا تحكم على الآخرين بناء عن ما ترى، وتعامل مع الآمر بأن جميع من سبقكك كانوا يطبقون ما يستطيعون في ظل ظروف مختلفة تمام عن ظروفك
- تولى مسؤولية الأمر، بمعنى أنه من الآن وصاعد أنت المسؤول عن هذا الأمر ولا يمكن دائما الحديث بصيغة “لست من فعلت هذا!”
- ابدأ بالتعامل مع هذا الأمر بشكل تدريجي ومقسم.
لذلك وكأي أمر مبهم، يمكن إتباع الخطوات التالية لتحقيق الغاية النهائية وهي إمكانية التعامل مع النظام القائم والتطوير عليهسنفصل كل خطوة من هذه الخطوات
- التحقيق، والتنقيب عن ما هو متاح
- الإختبار الأولي والتجهيز لبيئة إختبارية
- رسم المحددات والبدء بالتطوير مع دفع الدين التقني
التحقيق، والتنقيب عن ما هو متاح
نعم هذه هي الخطوة الأولى للبدء بتولي زمام الأمور، فقد تجد معلومات متاحة توفر عليك أيام من العمل من البحث والتدقيق.إليك بعض هذه الأماكن التي يمكنك من خلالها أن تجد سياق يساعدك في فهم أفضل للبرمجيات والنظام القائمة.
- ملف ال Readme الخاص بالمشروع
- ال wiki الخاص بالمشروع
- مراجعة ال issues عن طريق تتبعها إن وجدت
- مجلدات الإختبارات الخاصة بالمشروع إن وجدت
- تعليقات المكتوبة في الكود داخل البرمجيات
- أي ملفات مكتوبة خاصة بالمشروع
- أي شخص عمل على المشروع أو كان جزءا منه
كل هذه الأماكن تساعدك عن فهم السياق، ولكن يمكن أن لا يكون أي منها موجود، وبكل الأحوال في حال وجودها فهي عنصر مساعد ينبغي الإستعانه به، وفي حال لا يوجد أي من ذلك، فيمكنك رسم مخطط عام يساعدك في فهم النظام من نطاقه الخارجي.
أهم قاعدة يمكن أن تستعملها هو لا تحاول فهم كل شيء داخل المشروع، فقط حاول أن تفهم الصورة من الخارج.
الإختبار الأولي والتجهيز لبيئة إختبارية
الآن وبعد أن جمعت المعلومات المتاحة ورسمت صورة عامه عن النظام، لنبدأ بتجربة تجهيز المشروع للعمل على بيئة غير حية بمعنى بيئة إختبارية لتجربة النظام وفهم كيفية تشغيله وتوقيفه والتعامل معه لذلك من الممارسات المفضلة والتي تساعدك في توفير وقت هو عمل بيئة معزولة بإستخدام أنظمة العزل Containerize مثل Docker وبالتالي عمل بيئة معزولة بكل متطلباتها الخاصه حتى وإن كانت قديمة.
أيضا في حال توفر إختبارات للمشروع يمكنك التأكد من تفعيلها خلال هذه المرحلة لتعرف أكثر عن ماهية المشاكل التي تواجهك حاليا، ربما لا يكون هذا الأمر متاحا بشكل كامل أو جزئي، ولكن في حال توفره يمكنك إستعماله للإستدلال عن المشاكل.
رسم المحددات والبدء بالتطوير مع دفع الدين التقني
بعد أن إستطعنا تحقيق الفهم العام للنظام والقدرة على تشغيله ضمن بيئة إختبارية وتناول جميع المصادر المتاحه لفهم السياق، نأتي لنقطة الفعل وهي البدء بالتنفيذ والتطوير على المشروع.
هناك إنتصارات سريعة يمكن تحقيقها بمجرد البدء بالتطوير:
- حذف الكود الغير مستعمل مباشرة دون التفكير وفهمه وهو ما يسمى Dead code هذا الكود يقوم المبرمجين بوضعه حتى لا يضيع أو لربما يحتاجونه في المستقبل، عليك أن تقوم بحذف هذا الكود دون تفكير.
- حسن الكود بينما تحاول فهمه من خلال ال Refactoring أو إعادة بنية التعليمات البرمجية كنت قد كتبت مقالة سابقة عن ذلك يمكنك الإطلاع عليها من هنا، هذا سيساعدك على الفهم والتحسين في الوقت ذاته.
- في محاولتك لقراءة الأجزاء المهمه من الكود، حاول مثلا إعادة تسمية المتغيرات إلى متغيرات مفهومه لك، أيضا في حال وجود وظائف أو Functions معقده يمكنك فصل الجزء المعقد إلى وظائف والتعامل معها بشكل منفصل.
هل أترك الكود الموجود على حاله أم أقوم بتغييره؟
هذا الأمر نسبي، ففي حال وجدت أن الكود بطيء جدا، أو أن هناك خطورة عاليه، أو مشكلة يمكن حلها، فيمكنك تغيير ما يلزم لجعله يعمل على النحو الذي تطلع له ولكن المسأله هنا تتلخص بأنه يجب ربط هذا الأمر بهدف واضح وليس التغيير فقط للتغيير.
يمكن أيضا إستخدام التجارب للتحقق من أن ما تقوم به يعمل دون مشاكل مثل مكتبة Github Scientist والتي تساعدك على إبقاء نسختين من الكود لمعرفة النتيجة من التغييرات التي تقوم بها.من الآن فصاعدا يمكنك دائما بداية ممارسات سليمه من كتابة كود منظم، عمل إختبارات أساسية أو إتباع ال TDD لتغطية الكود بالإختبارات.
أشياء يجب أن تبقيها دائما ضمن الدين التقني الذي تقوم بسداده
بعد أن بدأنا فعلا بالتنفيذ والتصرف على الكود والتطوير هناك أشياء من المهم إعتبارها لضمان إستمرارية مستقبلية
- إنشاء تغطية اختبارية للنظام الأساسي
- تحديث مستودعات التعليمات البرمجية وإنشاء بيئات محددة جيدًا (Development, Staging, Production)
- تنفيذ CI/CD للتحقق من أي تحديثات جديدة تلقائيًا في كل بيئة.
- تحديث البنية التحتية ومعمارية النظام (الإصدارات والتوافق ….)
- إعادة البناء وتحسينات التعليمات البرمجية Refactoring
بالنهاية ما يمكننا القول به أنه لكل وقت قرارته الخاصه به، وهذه توجيهات تساعدك في تولي زمام الأمور والتحكم، لكن قد يكون من الممكن بمكان عدم تنفيذ أي منها لتحقيق هدف عمل خاص والحالة والسياق تلعب دورا حيويا في تحديد الإتجاه والقرار اللازم لأفضل الممارسات.
أتمنى أن تساعدكم هذه المقالة في التعامل مع الدين التقني والكود القديم، دمتم بود إلى تدونية أخرى