Технические долги можно разделить на несколько категорий. Например, по ущербу, который наносят долги, хотя конечный результат их воздействия на проект, разумеется, один и тот же – повышение затрат на разработку.
Это самый простой и очевидный тип долгов. Они накапливаются, если программист, архитектор, QA или любой другой член команды делает ошибки при разработке проекта, неверно применяя шаблоны проектирования или неправильно используя принципы проектирования.
В то же время это самый опасный тип долгов, так как участники разработки не видят рисков. Они не могут правильно оценить время на добавление новой функциональности или реорганизации уже работающей системы.
Это долги, которые характерны для более матёрых программистов: их делают намеренно для того, чтобы разработка достигла нужных результатов. Другими словами, умышленные техдолги – это результат осознанного компромисса между сроками, качеством и стоимостью работ.
При разработке проекта мы всегда стараемся оставить его в состоянии наиболее выгодном для будущих изменений, сделать его более гибким. Однако в реальном мире мы пишем код и создаём интерфейсы для коммерческого использования, то есть в условиях конкуренции, когда нужно завоёвывать рынки и опережать конкурентов бизнеса. Поэтому наступают моменты, когда сроки поджимают, руководитель проекта слышать не хочет про качественный код и проработку дизайна: ему нужен результат, причём быстро.
Мы начинаем действительно быстро писать код, автоматизировать только самые ключевые тестовые сценарии и прорисовывать в макетах только самые важные элементы. Оставляем дублирование в коде, неконсистентность в макетах, не пишем достаточно тестов в надежде, что после выхода очередной версии продукта всё исправим.
Но правда заключается в том, что может никогда не выпасть шанс, что мы возьмём эти исправления в работу. Ни после текущего релиза, ни после какого-то другого. К тому же если мы опустили планку качества в проекте, то эта планка будет падать с ускорением всё ниже и ниже[97].
Без целенаправленного процесса по снижению техдолгов эти долги только растут. Почему так происходит, рассмотрим чуть позже.
Эти долги лежат у самого основания нашего проекта. С ними мы миримся и договариваемся о том, что они являются нормой. К примеру, мы не будем поддерживать Oracle ни в какой версии нашей системы. С таким утверждением можно вполне спокойно развивать проект. Или, например, система будет иметь пользовательский интерфейс на react.js, который в будущем может устареть и стать не актуален для разработки. Если приходится платить по этим долгам (например, всё-таки произойдёт переход с react.js на новый фреймворк), то в конечном счёте по деньгам это сопоставимо с созданием нового приложения.
Об умышленных долговременных техдолгах нужно знать, но брать их в работу каждую итерацию не нужно.