الديون التقنية تقتل شركتك الناشئة. وإليك كيفية اصلاحها.

ينفق مهندسوك42% من ساعات عملهمالتعامل مع الديون الفنية والتعليمات البرمجية السيئة. لا بناء الميزات. عدم شحن المنتجات. إصلاح الاختصارات التي اتخذها شخص ما قبل ستة أشهر لأن الموعد النهائي كان بالأمس.

بالنسبة لشركة ناشئة تضم خمسة مطورين يكسب كل منهم 100 ألف دولار، فهذا يعني تقريبًا125.000 دولار سنويافي الراتب الهندسي المتجه نحو خدمة الديون. على الصعيد العالمي، تكلف الديون الفنية الشركات أكثر من 2.4 تريليون دولار سنويًا. ويزداد الأمر سوءًا: فالفرق التي لديها ديون غير مُدارة تشهد انخفاضًا في سرعة العدو بنسبة 30٪ في غضون 12 شهرًا.

الديون الفنية ليست مشكلة في الكود. إنها مشكلة تجارية. ولها الإصلاح.

كيف يبدو الدين الفني في العالم الحقيقي

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

يتراكم الدين الفني بطرق يمكن التنبؤ بها:

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

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

لماذا تتراكم الديون على الشركات الناشئة بشكل أسرع من أي شخص آخر

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

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

ينفق المهندسونمن 2 إلى 5 أيام عمل شهرياعلى الديون الفنية. وهذا يمثل ما يصل إلى 25% من ميزانيتك الهندسية المخصصة للحفاظ على القرارات التي اتخذتها عندما كان لديك معلومات أقل ووقت أقل. في شركة ناشئة مكونة من خمسة أشخاص، يعني ذلك أن إنتاج مهندس واحد يذهب بالكامل نحو خدمة الديون.

التأثير المركب هو القاتل. في الشهر الثالث، يبطئك الدين بنسبة 10٪. وفي الشهر السادس تكون 20%. بحلول الشهر الثاني عشر، تنخفض سرعة العدو بنسبة 30% عن ذروتها. الميزات التي كانت تستغرق سباقًا واحدًا تستغرق الآن جولتين. ارتفاع أعداد الأخطاء. تنخفض معنويات المهندس. يبدأ أفضل المطورين لديك بإجراء المقابلات في مكان آخر لأنهم سئموا من محاربة قاعدة التعليمات البرمجية بدلاً من بناء المنتج.

الأنواع الأربعة للديون الفنية (والتي يجب إصلاحها أولاً)

ليست كل الديون متساوية. إن التعامل معها كفئة واحدة يؤدي إما إلى تجاهلها كلها أو محاولة إصلاحها كلها مرة واحدة. لا يعمل.

متعمد وحكيم

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

متعمد ومتهور

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

غير مقصود وحكيم

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

غير مقصود ومتهور

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

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

نظام لسداد الديون الفنية دون توقف عمل المميزات

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

هنا هو النظام الذي يعمل.

الخطوة 1: إنشاء سجل الديون

قم بإنشاء مستند مشترك أو لوحة مشروع (جدول بيانات بسيط يعمل بشكل جيد) مع أربعة أعمدة: الموقع (ملف أو وحدة)، ووصف الدين، وتأثير الأعمال (ما الذي يؤدي إلى إبطاء ذلك أو تعرضه للخطر)، والجهد المقدر لإصلاحه. اطلب من كل مهندس في الفريق قضاء ساعة واحدة في إضافة العناصر. سوف ينتهي بك الأمر مع 20-50 إدخالات. هذا هو مخزون الديون الخاصة بك.

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

الخطوة 2: تخصيص 10-20% من كل سباق لتخفيض الديون

في سباق سريع لمدة أسبوعين مع خمسة مهندسين، 10% تعني أن مهندسًا واحدًا يقضي يومًا كاملاً في سداد الديون. 20% يعني يومين مهندسين لكل سباق. هذا ليس وقتًا اختياريًا؛ يتم جدولته وتعيينه وتتبعه مثل العمل المميز.

الرياضيات: يقوم فريق مكون من خمسة أشخاص بسباقات السرعة لمدة أسبوعين مع تخصيص ديون بنسبة 15%، وينفق 7.5 يومًا هندسيًا شهريًا على تخفيض الديون. على مدار عام، يعني ذلك 90 يومًا هندسيًا من التحسينات المستهدفة. يكفي لتحويل قاعدة التعليمات البرمجية دون إيقاف تسليم الميزات على الإطلاق.

الخطوة 3: إرفاق عمل الدين بالعمل المميز

الطريقة الأكثر فعالية لسداد الديون: قم بإصلاحها عندما تعمل بالفعل في المنطقة. بناء ميزة دفع جديدة؟ أعد بناء وحدة الدفع الحالية أثناء تواجدك هناك. هل تريد إضافة نقطة نهاية API جديدة؟ قم بتنظيف طبقة توجيه واجهة برمجة التطبيقات (API) كجزء من نفس طلب السحب.

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

الخطوة 4: قياس مقاييس الديون والإبلاغ عنها

لا يمكنك إدارة ما لا تقيسه. تتبع ثلاثة أرقام شهريا:

• نسبة الدين:النسبة المئوية لسعة العدو التي يتم إنفاقها على عمل الدين مقابل العمل المميز. الهدف: 10-20%. إذا تجاوزت 25%، فإن قاعدة التعليمات البرمجية تحتاج إلى تدخل أكثر قوة.
• وقت الدورة:المدة التي تستغرقها الميزة من "قيد التقدم" إلى "منشورة". يشير ارتفاع أوقات الدورة إلى تراكم الديون حتى عندما لا يشكو أحد من ذلك.
• تكرار الحادث:أخطاء الإنتاج في كل سباق. المزيد من الأخطاء في كل سباق يعني المزيد من الهشاشة الناجمة عن الديون. تتبع هذا جنبًا إلى جنب مع تكرار النشر لمعرفة ما إذا كانت سرعة الشحن مرتبطة بالكسر.

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

الوقاية: كيفية تراكم ديون أقل من اليوم الأول

سداد الديون الحالية أمر ضروري. إن تراكم ديون جديدة أقل هو الأفضل. فيما يلي الممارسات ذات أعلى عائد على الاستثمار.

• مراجعة الكود عند كل طلب سحب.زوج آخر من العيون يلتقط الاختصارات قبل أن تندمج. ليس من الضروري أن تكون المراجعات طويلة؛ مراجعة مدتها 15 دقيقة تكتشف 80% من أنماط خلق الديون.
• الاختبار الآلي من الأسبوع الأول.لا تحتاج إلى تغطية 100%. ابدأ باختبارات التكامل على مساراتك المهمة: الاشتراك، والخروج، والإجراء الأساسي الذي يجب على منتجك تنفيذه. وهذا يكلف 10-15% مقدمًا ويوفر 3-5 مرات في وقت إصلاح الأخطاء على مدار ستة أشهر.
• خط أنابيب CI/CD مع فحص النوع والفحص.الوضع الصارم لـ TypeScript، وESLint، والفحوصات الآلية في كل دفعة. تلتقط هذه الأدوات فئات كاملة من الأخطاء قبل أن تصل إلى مرحلة الإنتاج. يستغرق الإعداد نصف يوم. العودة دائمة.
• سجلات القرار للاختيارات المعمارية.عندما يقرر فريقك استخدام Redis للتخزين المؤقت، أو تخطي دعم WebSocket في الإصدار الأول، اكتب ملاحظة من فقرتين تشرح فيها القرار والمقايضات. وبعد ستة أشهر، عندما يسأل أحدهم "لماذا بنيناها بهذه الطريقة؟"، الجواب موجود ولا يعيد الفريق مناقشة سؤال محسوم.
• استئجار كبار المهندسين.مهندس كبير يكتب ديونًا أقل في المقام الأول. إنهم يختارون التجريد الصحيح، ويتوقعون اختناقات التوسع، ويبنون مع وضع الاختبار في الاعتبار منذ البداية. في Savi، نقوم بتوظيف المشاريع مع 1-2 من كبار المهندسين الذين يمتلكون المجموعة الكاملة. يتطلب الكود الذي يرسلونه صيانة أقل لأن القرارات المعمارية سليمة منذ اليوم الأول.

كل ساعة من الديون تمنعها هي ساعة توفرهاتكاليف صيانة البرامج المستمرة. الكود النظيف مع الاختبارات والبنية الصلبة يكلف 15-20٪ من البناء سنويًا للمحافظة عليه. تكاليف الكود المثقل بالديون 30-50٪.

متى تطلب المساعدة الخارجية

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

يستغرق التدقيق الخارجي من 3 إلى 5 أيام وينتج خطة سداد ذات أولوية مع ملفات ووحدات وتغييرات معمارية محددة مرتبة حسب تأثير الأعمال. يحدد المدقق نسبة 20% من الديون التي تسبب 80% من التباطؤ ويبني خريطة طريق يمكن لفريقك تنفيذها على مدار 8 إلى 12 أسبوعًا.

في Savi، نقوم بإجراء عمليات التدقيق هذه باستخدام تحليل التعليمات البرمجية المسرع بواسطة الذكاء الاصطناعي مقترنًا بمراجعة كبار المهندسين. أنماط إشارات الذكاء الاصطناعي (التعليمات البرمجية المكررة، معالجة الأخطاء المفقودة، التبعيات القديمة، الثغرات الأمنية). يفسر المهندس هذه العلامات في سياق عملك وحجم فريقك وخريطة الطريق الخاصة بك. الإخراج ليس تقريرًا عامًا؛ إنه تراكم جاهز للعدو السريع ويمكن لفريقك البدء في تنفيذه يوم الاثنين التالي.

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

الأسئلة المتداولة