К метафоре, описывающей накопление недостатков во внутреннем качестве продукта
На самом деле релиз может быть и не сырой, а даже полностью упакованный и готовый. И при этом все равно существует вероятность возникновения техдолга - например, не написали документацию. Вместо идеалистичной цели полного устранения техдолга (пишите в комментариях, почему это осуществимо или нет), можно научиться осознанно им управлять - то есть, если долг контролируется, он перестает быть такой ноющей проблемой и по сути превращается в инструмент работы с рисками.
Не пишите хреновый код, и не будет вам техдолга
Казалось бы, что мы часто слышим про техдолг в виде того, что надо пофиксить какие-то баги или поменять способ работы определенных модулей. В реале же масштаб зависит далеко не от качества или чистоты кода. Техдолг может возникнуть в любом моменте жизненного цикла ПО, буквально от требований до инфры, где все будет работать. При этом даже есть некоторая классификация, введенная Мартином Фаулером (там это даже раскладывается в квадрант).
Нормальный вариант, когда мы создаем техдолг осознанно для достижения тактических целей, например, для ускорения вывода продукта на рынок. При этом сразу же планируем его устранение. С другой стороны, в случае недостатка опыта или непонимания лучших практик, ну или от некачественного планирования, мы непреднамеренно создаем себе техдолг другого типа - можно даже не осознавать его наличие до того, как выстрелит. Есть еще вариант, когда мы тащим из проекта в проект старые библиотеки или платформы, что в будущем может привести к проблемам с совместимостью/безопасностью тупо из-за отсутствия поддержки
При этом естественно техдолг не возникает на ровном месте:
▫️Могут быть жесткие дедлайны или сроки, либо сильная динамика требований (тяжело влиять на это - вдруг у вас сильнорастущий бизнес), вплоть до смены стратегии
▫️Классика в неоптимальных процессах: допустим, отсутствие автоматизации тестирования, ну или плохое проектирование (влиять чуть легче)
▫️Может быть и недостаток компетенций (влиять легче всего)
Самое главное, это обнаружить скрытые угрозы и затем контролируемо над ними работать. По сути это и есть управление техдолгом, когда мы находим, оцениваем, планируем и устраняем его. Но при этом еще очень важно и предотвратить накопления нового долга!
Что делать?
Если вы внимательно читали предшествующие абзацы, я думаю вы уверенно ответите, что сначала техдолг надо обнаружить, или сделать видимым. Идем в обратном порядке от последствий к причинам: симптомы → последствия → технический долг → причины. Например, замедление разработки (симптом) может указывать на сложный для понимания код (технический долг), возникший из-за спешки при реализации (причина). Ну и анализируем все артефакты разработки: часто меняющиеся требования, монолитность, проблемы с масштабируемостью, отсутствие тестов, уязвимости, ручное развертывание, долгие и непрозрачные CI/CD-пайплайны.
Далее классифицируем по сложности устранения и срочности, и обязательно проводим экономическую оценку (не только стоимость исправления, но и стоимость отказа от исправления!).
Далее процессная база к устранению техдолга:
1️⃣Техдолг превращается в задачу
2️⃣Задачи приоритизируются
3️⃣Выделяем X% от спринта на техдолг
ну и еще 😎 про предотвращение непреднамеренного долга:
▫️Глубокий анализ требований, с документированием и вовлечением команды в обсуждение (вспоминаем дизайн-док)
▫️Применение архитектурных принципов, документирование решений, архревью (снова вспоминаем дизайн-док)
▫️Единые стандарты разработки, тестирование и статический анализ
▫️Ну и естественно мониторинги
Короче, техдолг это не проблемы, а про правильное управление ресурсами. Важно понимать трейдоффы и разные способы попадания в них. Ну а далее дело техники
Кстати, на Хабре есть очень хорошая статья по этой теме.
#softskills #career
