الدين التقني (Technical Debit) هو مجموعة من المشاكل تَسبب بها كود سابق تجعل من تقدمك أثناء البرمجة غير فعّال. الدين التقني يمتص انتاجيتك بجعل الكود صعب الفهم، سهل الانكسار، تعديله يأخذ وقت طويل، صعب الفحص ويخلق لك مشاكل غير متوقعة تٌأخر من التقدم. من أمثلة المشاكل المسببة للدين التقني الضعف العميق في التصميم والذي ينتج عنه كود سيء Code Smells.
مالم يتم التعامل معه، يتراكم الدين التقني حتى يقتل جودة البرنامج و إنتاجية الفريق على المدى البعيد. لا يمكن تفادي الدين التقني بالكامل، فما تبرمجه اليوم يُصبح ديناً عليك في المستقبل. ولكن هناك طرق كثيرة للتخفيف منه.
كيف نتعامل مع الدين التقني ؟ تختلف الطرق بحسب ما اذا كان النظام يتم تطويره الآن أم كان نظام قديم تم وراثته.
اذا كان النظام جديد فهذه أمثلة على طرق تقليل الدين التقني في المستقبل:
1- اختر هيكلة نظام غير مترابطة تمكنك من تطوير كل جزء على حدة تتواصل مع بعضها البعض عن طريق وسائل قياسية مثل HTTP. أمثلة على هذه الهياكل الحديثة المايكروسيرفسز Microservices حيث يمكن تطوير كل خدمة بشكل منفصل وحتى بتقنيات ولغات مختلفة وهذا يمكنك من التعامل معها في المستقبل بشكل منفصل أيضا.
يجب أيضا أن يكون هناك مالك ومنسّق لهذه الهيكلة يَعتمد التغييرات حتى لا تضيع هذه الاهداف مع الوقت.
2- اختر طرق تصميم برمجية معرفة مثل MVC، MVVM ، DDD وهكذا ومكاتب وإطارات عمل معروفة ولها مجتمعات معقولة الحجم مثل Angular أو شركات قوية خلفها مثل ASP NET CORE.
3- كتابة اختبارات فحص اتوماتيكية Automated Testing على مستوى الكود والواجهة اثناء تطوير النظام. هذا شيء مهم جدا يتم تغافله ولكنه سيساعد بشكل كبير جدا في معالجة الدين التقني مستقبلا. ويمكنك أيضا كتابة النظام بطريقة كتابة الفحص أولا والمعروفة ب TDD) Test-Driven Development).
إذا كان النظام سابق تم وراثة صيانته، فهناك بعض الطرق مثل:
1- ضع في حسابك جزء من وقت الفريق للعمل على الدين التقني يُقدّر ب 20% مثلا حتى يتم التحسّن التدريجي للنظام القديم وفي نفس الوقت اطلاق تحسينات جديدة وبالتالي يكون التأثير على العمل محدود. تأكد أنك تفصل ما تُحسّنه على شكل خدمة تتعامل مع بقية النظام كما ذكرنا في النقطة رقم واحد للأنظمة الجديدة حتى تُقلّل من الدين التقني في المستقبل ولا تكرر المشكلة.
2- أضف اختبارات فحص اتوماتيكية Automated Testing على مستوى الكود و واجهة النظام من أجل ان تعمل على تغيير الكود القديم وإجراء الفحص الوظيفي أتوماتيكيا مع التغييرات للتأكد من عدم حودث اعراض جانبية لتغييراتك. سيستغرق منك هذا الموضوع بعض الوقت للانظمة القديمة فلذلك يمكن اتباع فكرة ال 20% المذكورة في النقطة السابقة. في كل الأحوال يجب عمل اختبارات اتوماتيكية اثناء عمل التحسينات الجديدة.
3- هناك احتمال ان يكون النظام من الصعب تغييره بالكامل ولكن يجب أن يقرر هذا القرار شخص خبير في هيكلة النظم. في هذه الحالة افضل طريقة هي إنشاء فريق موازي ولو كان صغير من اجل العمل على النظام بشكل جديد وبطرق حديثة كالمذكورة سابقا. لكن بالتأكيد هذا مُكلف ولن يستطيع عمله الجميع. ولكن أيضا تأخير مثل هذا الشيء قد يقتل المنتج مستقبلا وحينها لن يكون عمل النظام من جديد مفيدا لأنه متأخر.
سواءا كنت تتعامل مع نظام جديد وتحت التطوير او نظام قديم فالمهم هو التعامل مع الدين التقني حالا وباستمرار وبدون تأخير حتى تتجنب مشاكل مستقبلية قاتلة.