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