الأعباء التقنية (Technical Debt)
يبذل المبرمج عادةً ما بوسعه لكتابة شيفرةٍ جيدةٍ، ولا ينوي أبدًا -أيًّا كان المبرمج- الحصولَ على شيفرةٍ رديئةٍ تكون السبب في فشل مشروعه البرمجيّ، لذا فلنطرح السؤال: ما هو الحدُّ الذي تصبح عنده الشيفرةُ النظيفةُ رديئةً؟
فخ الأعباء التقنية
اقتُرح مصطلح "الأعباء أو الالتزامات التقنيّة" (ويقابله بالانكليزيّة Technical Debt) للمرّة الأولى من قِبل Ward Cunningham، فإنه لدى اقتراضك مبلغًا ماليًا من أحد المصارف تكبُر أمامك فرصة الشراء بشكلٍ أسرع، ويحدث أن تدفعَ علاوةً (وأيّ إضافات أخرى) لتسريع الأمر والحصول على نتيجة مُرضية بوقتٍ قصيرٍ نسبيًا، ثم تضطر لدفع فوائد لهذا القرض وقد تصل قيمة الفوائد تراكميًا إلى ما يجاوز دخلك الحاليّ مما يجعل إعادة القرض كاملًا أمرًا مستحيلًا! وهذا تمامًا ما يحدث في الشيفرات البرمجيّة، إذ من الممكن تسريع الحصول على نتائجها بشكلٍ مؤقتٍ وبدون إجراء أيّة اختباراتٍ للميّزات الجديدة فيها، ولكن ذلك سيعرقل عملية التقدّم اليوميّ لاحقًا إلى أن تصل لمرحلة "ردِّ الدين" عبر إجراء الاختبارات من بعد الوقوع بالخسارات الكبيرة.
أسباب الوقوع بالأعباء التقنية
- ضغط العمل
قد تُجبرك ظروف العمل أحيانًا لنشر بعض الميّزات (features) قبل الانتهاء منها كلِّيَّا، وحينها ستظهر الكثير من المحاولات الإصلاحيّة في الشيفرة لإخفاء الأجزاء غير المكتملة من المشروع الإجماليّ.
- التغافل عن عواقب الأعباء التقنيّة
قد لا يكون الموظِّف (employer) على درايةٍ كافيّةٍ بما تفرضه الأعباء التقنيّة من تكلفةٍ ستحدُّ كثيرًا -عند تراكمها- من سرعة التطوير البرمجيّ، ويصبح آنذاك من الصعب تخصيص وقت فريق المبرمجين لإعادة التصميم (refactoring)؛ لأن الإدارة لن ترى أيّ طائلٍ -ملموسٍ- من ذلك ولن يكون الأمر ذا أهمية بالنسبة لها.
- الفشل بمعالجة الترابط الشديد ما بين المكونات البرمجيّة
يحدث هذا عندما يبدو المشروع كتلةً واحدةً أكثر من كونه ناتجًا عن وحداتٍ مستقلةٍ منفصلةٍ، وبهذه الحالة فإنّ أيّ تغييرٍ لجزءٍ من المشروع سيؤثِّر على الأجزاء الأخرى في المشروع، وبهذا تصبح عملية التطوير البرمجي التي يقوم بها الفريق أمرًا عسيرًا لأنه من الصعب الفصل بين عمل كلِّ فردٍ من الفريق على حِدة.
- إهمال إجراء الاختبارات
عند غياب التغذية الراجعة (feedback) الفوريّة والمباشرة ستزداد عمليات الالتفاف المحفوفة بالمخاطر، وذلك بهدف إجراء بعض الإصلاحات البرمجيّة، وبالحالة الأسوء سيُعرَّفُ استخدام (implement) التغييرات وتُوظَّفُ في الناتج النهائيّ بدون اختبارها أولًا، وتكون النتائج حينئذٍ كارثيّة! فمثلًا يمكن لرسالةٍ بريديّةٍ أن تُرسَل بهدف الاختبار إلى آلاف الموظفين، ويُتوقَع حدوث ما هو أسوء فقد يتسبَّب ذلك بتدمير قاعدة البيانات أو إفسادها بأكملها.
- صياغة توثيقيّة هزيلة
تنجم هذه المشكلة عند تقديم المشروع لمبرمجين (أو مطورين) جُدد، وتصبح مشكلةً حقيقيّةً عندما يترك الأشخاص الأساسيون المشروع دون وجود توثيقٍ واضح.
- غياب التواصل الفعّال بين أعضاء الفريق
إن لم تُوزَّع قاعدة المعارف (knowledge base) بشكلٍ شاملٍ لكامل أرجاء الشركة فسينتهي المطاف بالمبرمجين والمطورين إلى العمل وفقًا لمعلوماتٍ وعملياتٍ ملغيةٍ أو قديمةٍ من المشروع، وتتفاقم هذه الحالة عندما يتدرَّب المطورون الجُدد بطريقةٍ خاطئةٍ من قِبل مدربيهم.
- التطوير بعيد الأمد لعدّة فروع بوقتٍ واحدٍ
سيؤدي هذا إلى تفاقم الأعباء التقنيّة، والتي ستزداد بدورها عند إحداث التغييرات، إذ كلما كان هنالك تغييرات إفراديّة أكثر فستصبح الأعباء التقنية أعظم.
- تسويف عملية إعادة التصميم (refactoring)
تبقى متطلَّبات المشروع دائمًا بتغيِّرٍ مستمرٍ إلى أن تصبح أجزاء الشيفرة فيه مستهلكةً وقد تصبح معرقِلةً ببعض الأحيان، ويكون من الضروري حينئذٍ إعادة تصميمها لتلبية الاحتياجات الجديدة، ومن جانبٍ آخر يستمر مبرمجو المشروع بكتابة الشيفرات التي تتوافق مع الأجزاء القديمة المستهلكة من المشروع، إذ كلما تأخرت عملية إعادة التصميم يزداد عدد الشيفرات التي سيُعاد العمل عليها مستقبلًا.
- لا رقابة للالتزام بالنمط المُوحَّد
وهذا يحدث عندما يكتب كلُّ شخصٍ يعمل بالمشروع شيفرةً بحسب نظرته وطريقته الخاصّة (غالبًا بحسب آخر مشروع عمل به).
- الإلمام غير الكافي
وذلك عندما لا يعرف المُطوِّر كيفيّة كتابة شيفرة فعّالةً ومناسبة.