الكارما السيئة في البرمجة. ما هو الدين الفني وكيفية اصلاحه

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

ما هو الدين الفني؟

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

أسباب المظهر

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

تصنيف

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

1. الديون الفنية المتعمدة.

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

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

   نهج لحل هذا النوع من الديون الفنية

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

2. الديون الفنية التي تكون عرضية أو تنشأ من بنية المشروع القديمة.

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

   نهج لحل هذا النوع من الديون الفنية

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

3. الديون الفنية التي تنشأ مع مرور الوقت.

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

   نهج لحل هذا النوع من الديون الفنية

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

الحلول الفنية لإدارة الديون

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

1. خصص نسبة ثابتة من وقت عملك للعمل على الديون الفنية.

   إن الأمر المتعلق بالديون الفنية هو أنه لا يوجد وقت للعمل على التخلص منها (لأن هناك دائمًا مهام ذات أولوية أعلى) إلا إذا قمت بذلك بشكل هادف. لذلك، سيكون الحل الجيد هو تخصيص نسبة ثابتة معينة من وقت العمل لهذه الأغراض - حوالي 20-25٪.

   يمكن القيام بذلك بطرق مختلفة.

2. العمل على الديون الفنية يوم واحد في الأسبوع

   Если выделять на работу над устранением ТД всей командой один день в неделю, это How раз будет около 20% от общего рабочего времени. Для некоторых команд такой подход работает просто отлично и, говорят, даже повышает мораль, ведь в этот конкретный день недели вся команда занимается решением проблем, которые достают их все остальное время разработки.

3. Посвящать работе над ТД каждую четвертую задачу

   Такая система подходит тем командам, которые склонны разделять работу над проектом на примерно равномерные по времени и усorям для их выполнения задачи. Если один из каждых четырех тасков посвящать “выплате” ТД, это будет занимать около четверти всего времени разработки. А введение такого подхода в качестве правила позволит убедиться, что codeеры не будут откладывать технический долг “на потом”.

4. Переходящая роль

   Еще одним подходом к проблеме устранения технического долга будет назначать на данную задачу разных членов команды поочередно, чтобы равномерно распределить эту порой далеко не самую приятную работу среди членов коллектива. Количество разработчиков, назначенных заниматься “разгребанием” ТД, может быть разным — для команды из 4-5 человек будет достаточно одного, тогда How коллективы побольше могут назначать двух-трех. Но суть остается прежней — на работу над ТД должно уходить около 20-25% всех ресурсов и человеко-часов.

5. Правило бойскаутов.

   Правило бойскаутов состоит в том, чтобы всегда оставлять туристический лагерь (стоянку для палаток) в лучшем состоянии, чем он был до их прихода, то есть убирать даже тот мусор, который был оставлен не ими. Этот принцип, How выяснor заокеанские codeеры, отлично подходит и для управления техническим долгом. Согласно данному правилу, все члены команды должны заниматься исправлением ТД каждый раз, когда сталкиваются с ним в том or ином виде. Конечно, это правило нужно применять разумно, чтобы время, которое уходит на исправление ТД, не превышало “разумные” 25-30% от общих временных ресурсов.

6. Приоритизация “дорогого” технического долга

   Также эксперты в массе своей рекомендуют не забывать о том, что технический долг может различаться в том числе и по важности. Далеко не каждый тип ТД требует немедленного устранения, поэтому важно работать над классификацией разных видов технического долга и приоритезацией работы с ними соответственно. Проще говоря, прежде всего закрывать надо те долги, которые оказывают прямое влияние на speed разработки продукта, будучи частью его базовой архитектуры. Такие долги являются самыми опасными, потому что ведут к появлению новых долгов, которые могут расти How снежный ком.

Заключение

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