5 Signs Your Codebase Is Punishing Your Team

Представьте: команде понадобилась неделя, чтобы добавить экспорт CSV в админку. Два разработчика, все требования описаны, а самой работы — максимум на день. Остальное время ушло на попытки понять существующий код и безопасно внести изменения.

Автор статьи называет это явление Codebase Drag — сопротивление кодовой базы, которое замедляет любую задачу.

1. The Apology Estimate

Фича выглядит как задача на 2–3 дня, а разработчики называют две недели.

Просто они знают, что изменение кода в одном месте может затронуть всю систему и привести к неожиданным последствиям. Поэтому закладывают дополнительное время на фичу.

2. Deploy Fear

Это классика, про которую слышали все.

Команда избегает выкатывать изменения по пятницам или вообще после среды.
Каждый релиз воспринимается как потенциальный инцидент.

По метрикам DORA лучшие команды деплоят по требованию и удерживают долю неудачных изменений ниже 5%. В примере из статьи команда делала один деплой в неделю и каждый раз затаивала дыхание.

3. The “Don’t Touch That” File

В каждом проекте есть тот самый модуль, про который говорят: «Лучше туда не лезть».
Со временем вокруг него начинает разрастаться новый код, а проблема только усугубляется.

4. The Coverage Lie

Покрытие может показывать 80%, но критически важные части системы остаются без проверок.
Тесты проходят, а прод продолжает ломаться.

Прогон CI занимает 40 минут, а новые тесты делают его ещё медленнее.

В какой-то момент разработчики перестают запускать тесты локально.
В итоге метрика покрытия врёт дважды: тесты не проверяют самое важное, а часть из них вообще никто не запускает.

5. Time to First Commit

Если новому разработчику нужны недели, чтобы поднять проект и внести первое изменение, то это уже звоночек о накопившейся сложности системы.

В здоровой кодовой базе на это уходит день-два. README актуален, окружение поднимается без танцев с бубном, тесты запускаются локально. В проблемных проектах этот процесс может занимать недели.

Главная мысль статьи:
технический долг — это не только баги и плохой код, это ещё и постоянный налог на скорость команды.
Чем выше этот налог, тем больше времени уходит не на создание нового, а на борьбу со сложностью существующей системы.

Именно поэтому добавление новых процессов, митингов или даже AI-инструментов часто не даёт ожидаемого эффекта.
Если фундамент проекта мешает работать, сначала нужно инвестировать в его оздоровление.

В конце автор предлагает провести простой Codebase Drag Audit.
Для каждого из пяти признаков выставляется оценка от 0 до 2 баллов.
Если суммарно получается 4 балла и больше, то кодовая база уже требует целенаправленных инвестиций.
По мнению автора, до этого момента любые попытки ускорить команду будут давать ограниченный эффект.

Неплохое упражнение для любого техлида или EM — чтобы оценить свою систему и понять, где вы находитесь сейчас.

@tldr_data