ما هي الديون التقنية، ولماذا تكلفك المال بصمت؟

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

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

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

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

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

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

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

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

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

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

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