الدين الفني يشبه القرض. كلما طال تأجيل سدادها ، زادت الفائدة التي تدفعها

كيفية التعامل مع الديون الفنية في سكروم

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

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

1. استخدام استعارات قوية

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

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

2. تحمل المسؤولية كمطورين

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

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

3. استخدم مقاييس الكود لتقدير الديون الفنية

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

  • التعقيد الحلقي: يحدد هذا المقياس مدى تعقيد الفئات والأساليب من خلال تحليل عدد المسارات الوظيفية في الكود (إذا / ثم / آخر ، رمز التبديل / الحالة ، إلخ) مقارنة بسطور التعليمات البرمجية المستخدمة. وكلما زاد التعقيد السيكلوماتي ، كلما كان الحفاظ على التعليمات البرمجية أكثر صعوبة ؛
  • تغطية الشفرة: نقص اختبارات الوحدة هو مصدر الديون الفنية. يمكن لمعظم IDEs وخوادم CI حساب مقدار الكود الذي تغطيه اختبارات الوحدة. هناك قاعدة جيدة تتمثل في التأكد من أن التغطية تظل كما هي على الأقل عند إضافة رمز جديد ؛
  • SQALE-rating: مقياس يوفر تقييمًا واسعًا لجودة البرنامج ، استنادًا إلى عدد من القواعد الداخلية. ينتقل المقياس من A إلى E ، مع وجود أعلى جودة. يمكن لمعظم الإضافات المتخصصة لجودة الكود حساب هذا التصنيف (انظر أدناه) ؛
  • عدد انتهاكات القواعد: يحسب هذا المقياس عدد القواعد التي تم انتهاكها من مجموعة معينة من اتفاقيات الترميز. تصنف الانتهاكات عادة في فئات ، من الحرجة إلى الثانوية ؛
  • تكلفة التأخير: يساعد هذا المقياس (غالبًا اليدوي) في توضيح مقدار الوقت الذي يخسره الفريق بسبب الدين الفني ؛
  • Bugcount: مع زيادة الدين التقني ، تنخفض جودة البرنامج. من المحتمل أن يزداد عدد الأخطاء. مراقبة عدد الأخطاء (الحرجة) التي تظهر منبثقة هو مقياس بسيط ولكنه مفيد للتتبع ؛

هناك العديد من الأدوات والمقاييس المتاحة لتحديد الديون التقنية. تعتمد معظم هذه الأدوات على "تحليل الكود الثابت" ويمكن تشغيلها غالبًا من داخل IDE أو من خوادم البناء والتكامل. لقد أدرجت بعض الأمثلة أدناه لإلهامك (والتي استغرقت مني حوالي 30 دقيقة للإعداد):

NDepend في العمل

NDepend هو مكون إضافي لبرنامج Visual Studio (.NET) يوفر مجموعة من المقاييس. من المفيد بشكل خاص تصنيف SQALE (من A إلى E) ، والنسبة المئوية للديون الفنية المتكبدة حتى الآن وعدد الأيام اللازمة لإصلاح ذلك (تقدير تقريبي ، بالطبع). يمكن لـ NDepend أيضًا إنشاء خريطة حرارة للصفوف التي تعتبر المرشحين الرئيسيين لإعادة البناء - وهي مفيدة جدًا. يوفر Visual Studio IDE (بدءًا من Professional) أيضًا عددًا من المقاييس المضمنة ، مثل Cyclometic Complexity.

خيار آخر هو SonarQube. تتكامل هذه المنصة بسهولة مع معظم خطوط أنابيب CI و IDEs وتقوم بأتمتة عدد كبير من مقاييس الشفرة (بما في ذلك تصنيف SQALE).

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

4. اجعل الديون الفنية شفافة على تراكم المنتج

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

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

أفكار ختامية

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

يمكنك دعمنا من خلال الشراء من متجر الويب الخاص بنا ، أو من خلال الانضمام إلى أحد أحداثنا أو من خلال أن تصبح راعياً.