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