Я провел много собеседований и на них кандидаты часто жалуются: "у нас в команде огромный техдолг, времени его исправлять не дают". И знаешь, в чём всегда корень? Не в том, что джуны фигачили говнокод. А в том, что в какой-то момент бизнесу было важнее зарелизить фичу к чёрной пятнице, чем нормально её спроектировать. Разработчик понял, что нужно сделать костыль, и сделал. Потому что иначе фичи в срок не было бы — а значит, не было бы бизнеса, который платит ему зарплату.
Это нормальная сделка. Бизнес говорит "нам нужно сейчас, потом разберёмся". Разработчик берёт долг и обещает потом его закрыть.
Проблема не в самой сделке, а в том, что бизнес почти всегда забывает про вторую её часть. "Потом разберёмся" превращается в "ну и так работает же, зачем переделывать".
И через два года новый продакт, который пришёл на готовое, открывает бэклог и видит ад. Его реакция? "Какие криворукие разработчики тут до меня работали". Никакого понимания, что эти криворукие разработчики тащили бизнес на горящих сроках три года подряд, пока он на других проектах сидел.
Поэтому когда у тебя в команде в очередной раз говорят "надо побороть техдолг" — спроси одну вещь. Сколько часов в спринте выделено на эту борьбу? Если ответ "ну, в свободное от задач время", это не борьба. Это вид, что вы что-то делаете.
Реальная работа с техдолгом — это когда команда официально берёт N% мощности спринта на рефакторинг. И не "пока сроки позволяют", а как защищённый бюджет.
Если такого нет — техдолг будет расти, пока кодовая база не станет нерабочей. И тогда уже не разработчики виноваты. Виноват тот, кто эти решения принимал.
👍 — Согласен, техдолг это решение бизнеса
🌟 — Долг это лично мой грех, я плохой разработчик (нет)