Часть 3/4: TDD — наш ремень безопасности.
Итак, в первой части мы нашли "бутылочное горлышко", а во второй части научились декомпозировать задачи по "Принципу Бургера". Команда начала поставлять ценность маленькими, быстрыми порциями.
Но тут возник новый, предсказуемый страх, особенно у CTO и тимлидов:
"Если мы вскоре будем выкатывать изменения "по 10 раз в день", как нам быть уверенными, что мы ничего не сломали? Мы же потонем в регрессионном тестировании!"
Это абсолютно справедливое опасение. Скорость без качества — это просто быстрый путь к падению прода. Чтобы двигаться быстро и безопасно, нам был нужен "ремень безопасности". И им стала практика TDD (Test-Driven Development) — разработка через тестирование.
—————
Что такое TDD простыми словами?
Это переворот мышления. Вместо классического подхода "сначала пишем код, потом его тестируем", мы делаем наоборот:
1️⃣Сначала пишем тест, который ПРОВАЛИВАЕТСЯ (Красный этап). Мы описываем в виде кода, как должна работать функция, которой еще не существует. Запускаем тест — он, естественно, падает, потому что кода нет.
2️⃣Потом пишем САМЫЙ ПРОСТОЙ код, чтобы тест ПРОШЕЛ (Зеленый этап). Наша задача — сделать так, чтобы тест как можно быстрее стал "зеленым". Никаких мыслей об идеальной архитектуре на этом шаге.
3️⃣И только потом улучшаем код (Рефакторинг). Теперь, когда у нас есть "зеленый" тест, который страхует нас от ошибок, мы можем смело улучшать код, делать его красивым, быстрым и правильным, постоянно запуская тесты и убеждаясь, что мы ничего не сломали.
—————
Этот цикл "Красный — Зеленый — Рефакторинг" стал для команды новой мантрой.
Почему это сработало?
Изначально команда сопротивлялась (как и абсолютное большинство):
"Это же дольше! Нам придется писать в два раза больше кода!".
Но уже через пару-тройку недель большинство увидело магию этого подхода:
🔥Железобетонная уверенность: Каждый маленький "бургер" кода, который создавала команда, был с самого рождения покрыт тестами. Ребята гораздо меньше стали бояться вносить изменения в старый код, потому что тестовый "щит" мгновенно сообщал, если что-то пошло не так.
🔥Ревью кода стало проще: Проверять код, к которому прилагаются понятные тесты, в разы легче. Тесты служат живой документацией, объясняющей, что именно должен делать код.
🔥Количество багов в проде сократилось на ~70%: Мы перестали находить глупые ошибки на этапе ручного тестирования или, что еще хуже, от пользователей. Автотесты отлавливали их за секунды.
🔥Ускорение, а не замедление: Да, в моменте написание кода с тестами занимает чуть больше времени. Но это с лихвой окупается экономией на ручном тестировании, поиске багов и исправлении поломок в будущем.
Мы научили команду писать качественный код и не бояться скорости.
Но оставался последний шаг: как убрать человеческий фактор и сделать эту проверку качества полностью автоматической и неотвратимой?🤔
Об этом — в финальной, четвертой части кейса, где мы с командой построим автоматический "конвейер доверия".
Как вам идея TDD?
Кажется сложной или, наоборот, логичной?
Поделитесь в комментариях! 👇
Всем системных и, по возможности, автоматизированных решений. 😁🙌
P.S. Очень буду ждать ваших реакций! 😻
#кейс #tdd #testdrivendevelopment #agile #devops #scrum #оргдизайн #управлениекомандами