Как понять, что пора автоматизировать технический долг
Если вы замечаете, что количество ошибок в коде растет, а скорость их устранения оставляет желать лучшего, то самое время начать автоматизацию и избавиться от технического долга.
Что такое техдолг, и по каким критериям можно понять, что настало время его оптимизировать — узнаете в нашей новой статье.
Это блог ИТ-компании Цифровые Привычки
Мы реализуем финтех-проекты для бизнеса с 2014 года. Создаем веб-сервисы и нативные приложения, ускоряем цифровизацию компаний.
👨🏻💻 Вступайте, чтобы быть в курсе вакансий.
👾 Подписывайтесь и узнайте о нас больше.
Что такое технический долг
Технический долг — это накопленные проблемы в коде. К ним относят отложенные задачи, устаревшие компоненты, нереализованные функции, запутанные алгоритмы, некорректные архитектурные решения и другие «костыли». Все они приводят к багам, дополнительным затратам времени на их исправление или на внедрение нового функционала.
Согласно отчету Software AG, в 2022 году ИТ-компании потратили на устранение техдолга более 20% общего бюджета. 58% опрошенных не имеют официальной стратегии по управлению им.
А по данным Stepsize, 66% разработчиков считают, что команда могла бы работать на 100% быстрее, если бы у них был процесс управления техдолгом.
Какие проблемы возникают из-за технического долга
Увеличение времени разработки
Накопившиеся задачи создают дополнительную нагрузку на команду. Разработчики вынуждены исправлять ошибки и улучшать код, написанный в спешке.
Снижение качества продуктов
Когда проект находится под жестким давлением сроков и бюджетов, разработчики могут идти на компромиссы и пренебрегать код-ревью.
Увеличение затрат на проекты
Если продукт выпущен с недоработками или ошибками, команда тратит больше времени и ресурсов на исправление проблем. При этом качество не увеличивается пропорционально.
Неудовлетворенность пользователей
Частые неполадки и ошибки в работе продуктов приведут к тому, что клиенты начнут искать альтернативу у конкурентов.
Уменьшение конкурентоспособности
Проблемы с качеством продуктов, удовлетворенностью пользователей и затратами на техническое обслуживание приводят к потери рыночной доли.
Как выявить технический долг
Критерий 1. Низкая степень модульности
Сложный код — верный признак растущего техдолга. Если код сложно разделить на отдельные модули, которые могут быть легко понимаемы и использованы, то проект становится большим, а значит есть вероятность, что архитектурные решения некорректны.
Критерий 2. Нарастающее количество ошибок
Особенно это касается случаев, когда проблема в коде возникает не единожды. Если разработчики уже несколько раз сталкивались с одной и той же проблемой, возможно дело не хард скиллах, а в системном сбое, который должен быть решен автоматически.
Критерий 3. Метрика «Отток кода»
Code Churn — показатель, который подсчитывает, сколько раз в конкретной строке код удалялся, заменялся или переписывался. При разработке новой функции отток неизбежен, но после запуска новой версии отток кода должен уменьшаться.
Критерий 4. Метрика «Покрытие кода»
Code Coverage — с помощью показателя можно узнать, какой процент кода был протестирован. Низкое покрытие кода означает, что код содержит ошибки или он не был протестирован.
Критерий 5. Коэффициент технического долга
Technical Debt Ratio — метрика для расчета стоимости техдолга. В идеале ваш TDR должен быть около 5%. Единой формулы не существует, компании выбирают наиболее адекватный вариант для себя:
- TDR = Сумма технического долга / Годовая выручка• сумма технического долга — общее количество времени, затраченное на оптимизацию кода;• годовая выручка — доход, полученный от продукта за год.
- TDR = (Стоимость восстановления / стоимость разработки) × 100• стоимость восстановления может быть рассчитана как функция метрик качества кода: «Отток кода» и «Покрытие кода»;• стоимость разработки — количество строк кода, необходимых для создания продукта или функции, разделенный на средние затраты ресурсов на одну строку.
Критерий 6. Ручной тестировщик не справляется
QA находят много проблем. И тогда стоит посмотреть на метрику «Покрытие кода» с помощью юнит-тестов.
Варианты автоматизации технического долга
Чтобы успешно управлять техническим долгом, мы рекомендуем:
- регулярно проводить аудит и код-ревью;
- включить рефакторинг в план работы на регулярной основе;
- вовремя обновлять инструменты, фреймворки и библиотеки;
- использовать модульную архитектуру и четко обозначать свою позицию по отношению к техдолгу в новых компонентах или библиотеках;
- внедрять инструменты для автоматического анализа кода и выявления потенциальных ошибок.
Например, наша система оптимизации работы с техдолгом CodeAche сама анализирует код, оценивает нарушения, зависимости и уязвимости в исходном коде.
Как CodeAche оптимизирует технический долг
Контролирует качество
Система поможет управлять объемом техдолга, качеством кода в своих продуктах и подключаемых сторонних библиотеках. Планируйте время на ликвидацию техдолга с учетом критичности проблем и принимайте решения на основании данных анализа.
Создает безопасный код без ошибок
С системой вы выявите участки кода, которые могут привести к неправильной работе программы или к отказу системы. Можно формировать профили с собственными наборами проверок и устанавливать требуемое качество кода.
Экономит время и стоимость разработки
В системе есть возможность создания задач на основании найденных проблем. Это позволит не потерять работу в бэклоге команды. Вы сможете планировать исправления проблем из одного файла в коде и повысить скорость разработки.
Технический долг может привести к серьезным проблемам для ИТ-компаний. Чтобы избежать багов, компании должны регулярно оценивать нарушения и внедрять инструменты по автоматизации процессов. Это позволит улучшить качество продуктов, облегчить работу команды, удовлетворить потребности клиентов и сохранить свою конкурентоспособность на рынке.
Проанализируйте техдолг своего продукта с помощью CodeAche!
Ерунда без задач. В командах где руководство понимает про технический долг и так выделяют время на то чтобы всё исправить по необходимости, в тех где нет-даже формальные метрики не помогут особо, ибо проблема обычно глубже, в подходах как таковых, и без понимающего проблему тимлида или ещё какого технического руководителя ничего не поменять.
Спасибо за комментарий 👍🏻 Мы понимаем, что на техдолг нужно закладывать время. Но иногда такого долга становится настолько много, что разработчикам придётся создавать новую версию, учитывая все прошлые ошибки. А автоматический инструмент поможет сократить время работы.
Комментарий недоступен
Опять какихто бомжей погнали ссаными тряпками с хабра
Здравствуйте! Эту статью мы не публиковали на Habr)
У нас 200+реализованных проектов в области цифровизации и больше 10 собственных технологических решений, зарегистрированных в реестре отечественного ПО. Просим вас не писать дезинформацию по поводу нашей экспертности.
Ммм, линейный график и y^2 бахнули, на основе данных, а не для красоты и убедительности конечно же? :))
Верно, этот график мы отрисовали без данных. С помощью инфографики показали, что такое техдолг (не y^2, а просто использовали кривые 😉).