Умышленные
Это долги, которые характерны для более матёрых программистов: их делают намеренно для того, чтобы разработка достигла нужных результатов. Другими словами, умышленные техдолги – это результат осознанного компромисса между сроками, качеством и стоимостью работ.
Кратковременные
При разработке проекта мы всегда стараемся оставить его в состоянии наиболее выгодном для будущих изменений, сделать его более гибким. Однако в реальном мире мы пишем код и создаём интерфейсы для коммерческого использования, то есть в условиях конкуренции, когда нужно завоёвывать рынки и опережать конкурентов бизнеса. Поэтому наступают моменты, когда сроки поджимают, руководитель проекта слышать не хочет про качественный код и проработку дизайна: ему нужен результат, причём быстро.
Мы начинаем действительно быстро писать код, автоматизировать только самые ключевые тестовые сценарии и прорисовывать в макетах только самые важные элементы. Оставляем дублирование в коде, неконсистентность в макетах, не пишем достаточно тестов в надежде, что после выхода очередной версии продукта всё исправим.
Но правда заключается в том, что может никогда не выпасть шанс, что мы возьмём эти исправления в работу. Ни после текущего релиза, ни после какого-то другого. К тому же если мы опустили планку качества в проекте, то эта планка будет падать с ускорением всё ниже и ниже[97].
Без целенаправленного процесса по снижению техдолгов эти долги только растут. Почему так происходит, рассмотрим чуть позже.
Долговременные
Эти долги лежат у самого основания нашего проекта. С ними мы миримся и договариваемся о том, что они являются нормой. К примеру, мы не будем поддерживать Oracle ни в какой версии нашей системы. С таким утверждением можно вполне спокойно развивать проект. Или, например, система будет иметь пользовательский интерфейс на react.js, который в будущем может устареть и стать не актуален для разработки. Если приходится платить по этим долгам (например, всё-таки произойдёт переход с react.js на новый фреймворк), то в конечном счёте по деньгам это сопоставимо с созданием нового приложения.
Об умышленных долговременных техдолгах нужно знать, но брать их в работу каждую итерацию не нужно.
«Запах» кода с долгами
В вашем, в моём и любом другом проекте есть техдолги. Вопрос в том, насколько сильно они влияют на разработку в данный момент. Существует критический порог, за который не стоит заходить, иначе проект остановится и уйдёт в бесконечный фиксинг проблем, во время которого бизнес не получит ни одной новой функции.
Чтобы понять, что вы приближаетесь к пропасти из техдолгов, обратите внимание на эти признаки:
1. Любое изменение системы приводит к ряду новых дефектов. Запутанность в коде, сильное связывание всех частей проекта, отсутствие тестов приводит к каскаду проблем. Это можно заметить, когда, казалось бы, несвязанные между собой функции влияют друг на друга. Например, из-за изменения способа отправки электронных писем перестаёт корректно работать отображение списка этих писем в личном кабинете. В таком проекте трудно двигаться вперёд. Если качество системы низкое, то во время разработки постоянно будут вылезать поломки в некогда работающих частях системы.
2. Команда разработчиков постоянно встречается с непредвиденными проблемами. Это могут быть проблемы разного характера. Например, невозможность расширения потоков документов, проблемы с переходом на другой провайдер по передаче SMS-сообщений. Если дизайн системы не предполагает её изменения в дальнейшем (сильное связывание компонентов, раскрытие внутренностей объектов, глобальные переменные), то это всегда будет приводить разработчиков к неожиданным затруднениям при изменениях, а изменения в живом продукте, как мы знаем, идут без остановки.
3. Уже исправленные дефекты снова появляются. Обычно это происходит, когда нет достаточного покрытия тестами, система плохо спроектирована и в коде много дублирования. Причины вполне очевидны. Если мы нашли ошибку в программе, например, отсутствие проверки на граничные значения, и написали на эту ошибку автоматический тест, то теперь на протяжении жизни проекта этот тест будет гарантировать, что такая ошибка не появится вновь. Неверное исправление кода приведёт к падению теста, мы вовремя заметим проблему и исправим. Если же такого теста нет и ваш коллега поправил код так, как ему этого хочется, то ошибка может вернуться.
Если вы заметили один из этих признаков или нечто похожее на эти проблемы – пора сделать аудит системы и посчитать свой техдолг. Даже если окажется, что техдолг большой, то лучше знать об этом заранее, чем в дальнейшем «неожиданно» столкнуться с последствиями в виде закрытия проекта.
Когда начинаем платить?
Рассмотрим влияние долгов на развитие проекта в динамике. И наибольший интерес представляет сравнение двух разных подходов[98]: разработка проекта с хорошим внутренним дизайном кода, с тестами и без этого (рис. 60).
Рис. 60. Момент платы за технические долги
На рисунке показана скорость, с которой команды наращивают функциональность в проекте. Команда синих забыла о дизайне кода и о тестах. Она решила в кратчайший срок добиться впечатляющих результатов.
Команда красных идёт проверенной дорогой. Они уделяют особое внимание качеству кода, пишут тесты и заботятся о расширяемости системы.
Как можно увидеть, команда синих довольно значительно обошла команду красных по скорости в начале. Но со временем их продуктивность падает. Они начинают тратить дополнительное время на поддержку системы, а точнее, на оплату техдолга. Точка пересечения производительности двух команд – это время, когда команда синих начинает очень много платить за долги в коде.
В это время команда красных уверенно и равномерно идёт вверх. Вообще, обратите внимание, что равномерная поставка новых фич является признаком высокого качества системы и профессионализма команды. Равномерность показывает, что команда контролирует техдолг и достаточно вкладывается в качество системы.
Напрашивается простое решение для синей команды – когда они начинают платить за долги, им нужно перепрыгнуть на путь красной команды. К сожалению, в этот момент уже слишком поздно надеяться на получение стабильного роста, так как долги в коде дадут о себе знать. Если команда синих начнёт вкладываться в качество, то какое-то время не будет прироста новой функциональности будет близко к нулю, но зато потом они могут выйти на параллельный тренд с красной командой.
Напрашивается вывод, что если команде нужно сделать «быстрый» продукт, например, его промоверсию для демонстрации и получения инвестиций на основной проект, то вполне подойдёт тактика синей команды. Однако с такой тактикой не стоит рассчитывать на длительные проекты.
Динамика нарастания долгов
Теперь рассмотрим динамику нарастания долгов и их оплату. Красная линия показывает затраты, которые нужно вложить, чтобы полностью убрать техдолг (рис.