Технический долг есть в любом крупном проекте. Он возникает, когда копятся компромиссные решения, проблемы в коде или архитектуре. Важно, что эти решения и проблемы усложняют и удорожают поддержку и обновление кода в будущем. Это своеобразные «проценты». Чем больше долг, тем больше «процентов» приходится платить.
В статье поделимся опытом работы с техдолгом. Сначала определим, что это, затем подумаем, как решать.
Примеры техдолга
- Команда не пишет юнит тесты. От этого в коде появляется все больше ошибок, что увеличивает время разработки нового функционала. Отсутствие юнит-тестов — это техдолг. Все хорошие программисты знают, что юнит-тесты должны писаться всегда, это неотъемлемая часть кода. Можно считать, что без тестов фича не сделана.
- Сейчас команда решает сделать упрощенную архитектуру, а нюансы и улучшения «сделают потом». Однако «потом» так и не наступает, и компромиссная архитектура приводит к проблемам с развитием проекта.
- Еще один пример — отсутствие документации. Очевидно, что без нее доработка и поддержка становятся очень сложными. Особенно, когда на проект приходят новые люди.
Причины технического долга
- Ошибки управления проектом. Очень сжатые сроки приводят к компромиссам. А когда такой метод управления становится постоянным, у команды нет времени сделать необходимые изменения. Также нехватка времени возникает, когда оценка проекта/фичи сильно занижена. Встречается нежелание исправлять техдолг на уровне управления. Например, команда хочет упразднить техдолг, но управляющие не желают тратить на это время (либо команда не может обосновать необходимость). Иногда сложно объяснить бизнесу, что надо потратить пару недель, чтобы привести все в порядок, так как за это время они не получат новых фич.
- Низкая культура программирования, нехватка знаний и опыта у команды. Техдолг накапливается даже тогда, когда все хорошо, никто не стоит с пистолетом за спиной. Если команда не контролирует стиль и качество кода, применение современных практик разработки (тесты, документация, рефакторинг, continuous integration), то со временем накопится огромный багаж техдолга.
Каким бывает техдолг
Можно разделить техдолг по приоритетам. Что быстрее и больнее отразится на скорости разработки, на качестве приложения, и что менее важно. Так проблемы в архитектуре выглядят важнее и опаснее, чем отсутствие юнит тестов.
Техдолг ничем не отличается от фич или багов. Их можно и нужно оценивать и держать на доске наравне с обычными задачами. Только так можно отслеживать накопление или уменьшение долга.
Техдолг проявляется в коде отсутствием тестов и документации. Он копится, когда не проводится регулярный рефакторинг. Много TODOшек, FIXMEшек в коде тоже могут сигнализировать о техдолге.
Как уменьшить технический долг
Самый действенный способ уменьшить техдолг — не допускать его. Нельзя начинать проект со строчки кода и первого класса. Первым делом нужно принять стандарты и стиль кодинга, интегрировать инструменты, которые будут измерять качество кода, покрыть код тестами, создать структуру документации. Если сделать это заранее, долг будет накапливаться медленнее.
От техдолга нужно постепенно избавляться. Регулярно добавлять связанные с этим задачи в разработку, обосновывать и защищать перед заказчиком необходимость таких изменений. Если техдолг есть сейчас, в будущем нельзя допустить подобной проблемы. Окей, у нас есть классы, не покрытые тестами. Значит все новые классы и методы нужно ими покрыть. В этом случае техдолг по тестам точно не будет расти.
Как объяснить бизнесу, что с техдолгом нужно работать
Техдолг страшен «процентами». Проблемы и компромиссы в архитектуре приводят к неработоспособности приложения. А плохое качество кода — причина долгой разработки, кучи ошибок. Все это можно объяснить, а самое главное — показать. Хотите продемонстрировать страдающее качество кода, представьте бизнесу сколько багов находят клиенты. Покажите отчет, отражающий, как падает производительность команды, насколько меньше делаете фич по сравнению с более ранним периодом. Из-за техдолга релизы происходят гораздо реже, а хочется, чтобы каждые пару недель.
Оцените баги, которые возникают из-за большого технического долга. Благодаря этому, можно оценить в днях работу, которая вызвана недоработками и плохой реализацией. Если технической долг есть на уровне архитектуры, можно замерить максимальную нагрузку, которую выдержит приложение. Эта цифра наглядно покажет заказчику, что можно выжать из текущего приложения. Если бизнесу нужно больше пользователей, потребуются вложения. Предложите делать новые фичи, параллельно решая задачи из техдолга.