ما هو الدين التقني؟ أسبابه وتكلفته وطريقة إدارته

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

ما معنى الدين التقني ومن أين جاء المصطلح

صاغ الاستعارة وارد كننغهام، أحد الموقّعين على بيان البرمجة الرشيقة (Agile). وكما يلخّصها مارتن فاولر، فإن الاختصارات في الكود تشبه المال المقترض: تكسب سرعة الآن، وتدفع فائدة لاحقاً في صورة جهد إضافي كلما عملت في ذلك الجزء من النظام.

يمكنك سداد أصل الدين بتنظيف الكود، أو الاستمرار في دفع الفائدة.

قيمة الاستعارة أنها تنقل الحديث من "المطورون يريدون إعادة الكتابة" إلى قرار تجاري واضح: ماذا اقترضنا، وكم يكلفنا، ومتى نسدده؟

الأنواع الأربعة للدين التقني

يصنّف مربع الدين التقني عند فاولر الدين وفق سؤالين: هل أُخذ عمداً أم دون قصد، وهل كان حكيماً أم متهوراً؟

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

كيف يبدو في موقعك

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

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

كم يكلّفك

فائدة الدين التقني تُدفع وقتاً ومخاطرة، لا بنداً في فاتورة. وأبرز أعراضها:

1. التعديلات البسيطة تأخذ أطول مما ينبغي، فيتحول حقل جديد في نموذج إلى أسبوع عمل.
2. الإصلاحات تُنتج أعطالاً جديدة، لأن أجزاء النظام مترابطة بطرق لا يراها أحد.
3. الإصدارات تبدو خطرة، فيؤجل الفريق التحديثات وتتأخر الحزم أكثر.
4. المطور الجديد يحتاج وقتاً طويلاً ليبدأ، لأن المعرفة في رؤوس الناس لا في الكود أو التوثيق.
5. تحديثات الأمان تتأجل، والحزم القديمة أصعب أنواع الدين رؤية وأغلاها تجاهلاً.

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

كيف تقيسه

لا يختصر رقم واحد الدين التقني. استخدم عدة مؤشرات وراقب اتجاهها لا قيمتها المطلقة:

• زمن التعديل الروتيني: كم يستغرق تعديل صغير محدد من الطلب حتى النشر؟
• فشل الإصدارات: كم مرة يحتاج الإصدار إلى إصلاح عاجل أو تراجع؟
• عمر الاعتماديات: كم تتأخر أُطر العمل والحزم عن آخر إصداراتها، وهل خرج أي منها من الدعم؟
• مناطق يتجنبها الفريق: أي ملفات أو خصائص يتردد الجميع في لمسها؟
• الأدوات الآلية: أدوات التحليل الساكن ترصد التكرار والتعقيد والثغرات المعروفة. اعتبر نتائجها قائمة أولية لا حكماً نهائياً.

تريد قراءة هذه المؤشرات في نظامك أنت؟ ابدأ بمراجعة تقنية.

كيف تديره

لن تصل إلى صفر، ولا ينبغي أن تحاول. الهدف أن يبقى الدين مرئياً ومقصوداً.

1. سجّله: احتفظ بسجل للدين في المكان نفسه الذي تتابع فيه بقية المهام، وتذكر كل مدخلة ما اقتُرض ولماذا وكم يكلف.
2. قرّر لكل بند: سدّده الآن، أو جدوله، أو اقبله. والقبول قرار سليم إذا كان الجزء نادر التعديل.
3. سدّد حيث تعمل: نظّف الأجزاء التي ستعدلها على أي حال، ففيها أعلى فائدة.
4. خصّص سعة ثابتة: حصة صغيرة منتظمة من كل دورة عمل أسهل حمايةً من "أسبوع تنظيف" يأتي مرة واحدة.
5. امنع النوع المتهور: الأنواع الصارمة للبيانات، ومراجعة الكود، وتوثيق القرارات، وجدول تحديث منتظم توقف معظم الدين غير المقصود قبل أن يبدأ.

ويمكن أن تكون مدخلة السجل قصيرة:

Debt: Checkout form validation duplicated in three places
Why: Shipped before launch; shared validation planned for after
Cost: Every rule change must be made three times; one copy is already out of sync
Decision: Pay down before the next checkout change

إعادة هيكلة أم إعادة بناء؟

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

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

كيف نُبقي الدين مرئياً في مشاريعنا

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

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

الدين التقني: أسئلة شائعة

هل الدين التقني سيئ دائماً؟

لا. الدين المقصود والمسجَّل قد يكون قراراً تجارياً سليماً، كأن تلحق بموعد إطلاق. ويصبح ضاراً حين يكون خفياً أو حين لا تُراجع فوائده أبداً.

من المسؤول عن الدين التقني؟

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

كيف أشرح الدين التقني لغير التقنيين؟

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

هل تكشف المراجعة التقنية الدين التقني؟

نعم. المراجعة الجيدة تحدد مواضع الدين وتكلفته وترتيب سداده. والمراجعة التي نقدمها تنتهي بنتائج مكتوبة وخريطة طريق يستطيع أي مطور العمل بها.

اكتشاف الدين في نظامك أنت

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