التكلفة الحقيقية للديون التقنية — وكيف تسدّدها دون إيقاف التطوير

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

ما الديون التقنية فعلًا؟

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

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

كيف يظهر الدين في أرقام العمل؟

لست بحاجة إلى قراءة الكود لاكتشاف دينٍ ثقيل؛ فهو يطفو في مؤشرات التسليم:

• ميزات كانت تستغرق أيامًا في العام الماضي تستغرق أسابيع الآن — في المنطقة نفسها من المنتج.

• المهندسون الجدد يحتاجون شهورًا قبل أن يتمكنوا من الشحن بأمان.

• التقديرات تفقد معناها، لأن كل مهمة تكشف مفاجآت.

• حصة متزايدة من كل دورة عمل تذهب إلى الإصلاح بدل البناء.

إذا انطبق اثنان أو أكثر من هذه على فريقك، فأنت تدفع فائدةً — سواء سمّاها أحدهم دينًا أم لا.

قِس قبل أن تعيد الهيكلة

إعادة هيكلة كل شيء خطأ بقدر عدم إعادة هيكلة أي شيء. الدين الأعلى فائدة يسكن في البؤر الساخنة: الملفات المعقدة وكثيرة التغيير في آن واحد. الوحدة المتشابكة التي لم يلمسها أحد منذ سنتين لا تكلّفك شيئًا يُذكر؛ أما الوحدة المتشابكة التي تُعدَّل كل أسبوع فهي حيث تتراكم الفائدة.

اجمع تحليل البؤر الساخنة (تكرار التغيير × التعقيد) مع مؤشرات التسليم — زمن الوصول ونسبة فشل التغييرات — فتحصل على قائمة مرتَّبة بما يجب إصلاحه أولًا، مبرَّرة بلغة الأعمال لا بالذوق الجمالي.

السداد دون إيقاف خارطة الطريق

١. خصّص ميزانية للدين

اجعل حصة ثابتة من كل دورة — ١٥ إلى ٢٠ بالمئة رقم شائع ومستدام — لخفض الدين في البؤر الساخنة. الميزانية الدائمة أفضل من «سباق إعادة هيكلة» لمرة واحدة، لأنها لا تحتاج إلى إعادة تفاوض أبدًا، ولا تعطّل خارطة الطريق أبدًا.

٢. طبّق قاعدة الكشّاف

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

٣. الاختبارات أولًا، ثم إعادة الهيكلة

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

٤. خنق النظام القديم بدل إعادة كتابته

مع الأنظمة القديمة فعلًا، استخدم نمط «شجرة التين الخانقة»: ابنِ البديل حول النظام القديم، وحوّل إليه حركة الاستخدام جزءًا فجزءًا، ثم أوقف الأصل بعد أن يفرغ تمامًا. يستمر العمل التجاري في الدوران طوال الوقت.

الخلاصة

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

قراءات إضافية

1. Refactoring: Improving the Design of Existing Code — مارتن فاولر.

2. Working Effectively with Legacy Code — مايكل فيذرز.

3. Your Code as a Crime Scene — آدم تورنهيل.