Scrum и XP: заметки с передовой

Я уже говорил, что TDD — это непросто, но что действительно сложно, так это пытаться применять TDD для кода, который изначально не был спроектирован для применения этого подхода! Почему? Эту тему можно долго обсуждать, но я, пожалуй, остановлюсь. Приберегу мысли для следующей книги: «TDD: Заметки с передовой»: o)

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

При выходе каждого релиза мы выделяли команду тестировщиков, которые выполняли весь набор сложных регрессионных тестов и тестов производительности. Регрессионное тестирование выполнялось преимущественно вручную, что существенно замедляло процессы разработки и выпуска релизов. Тогда нашей целью стало автоматизировать все эти тесты. Однако, побившись пару месяцев головой об стену, мы поняли, что не приблизились к цели ни на йоту.

Тогда мы изменили подход. Мы признали тот факт, что автоматизировать регрессионное тестирование нам не по силам, и задали себе вопрос: «Как можно уменьшить время тестирования?». Это была игровая система, и мы выяснили, что большую часть времени тестирующая команда тратит на тривиальные задачи, такие как настройку тестового турнира или ожидание начала турнира. Поэтому мы создали утилиты для выполнения этих операций. Маленькие, доступные нажатием горячих клавиш скрипты, которые выполняли всю подготовительную работу, позволяя тестировщикам сосредоточиться непосредственно на тестировании.

А вот эти усилия уже окупились сполна! По уму мы должны были поступить так с самого начала. Но мы были настолько зациклены на автоматизации, что забыли про эволюционный подход, в котором первым шагом было бы создание окружения, позволяющего сделать ручное тестирование более эффективным.

Усвоенный урок: Если от ручного регрессионного тестирования отказаться нельзя, но очень хочется его автоматизировать — лучше не надо (ну разве что это действительно очень просто). Вместо этого сделайте всё для облегчения процесса ручного тестирования. А уже после этого можно подумать и про автоматизацию.

Эволюционный дизайн

Это значит начать с простого дизайна и постоянно улучшать его, а не пытаться сделать всё идеально с первого раза и больше ничего и никогда не трогать.

С этим мы справляемся достаточно хорошо. Мы уделяем достаточно времени рефакторингу и улучшению существующего дизайна, и очень редко занимаемся детальным проектированием на годы вперёд. Иногда мы, конечно, можем напортачить, в результате чего плохой дизайн настолько врастает в систему, что рефакторинг превращается в действительно большую задачу. Но, в целом, мы полностью довольны этим подходом.

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

Непрерывная интеграция (Continuous integration)

Чтобы внедрить непрерывную интеграцию нам пришлось для большинства наших продуктов создать достаточно сложное решение, построенное на Maven и QuickBuild'е. Это архиполезно и экономит массу времени. К тому же это позволило нам раз и навсегда избавится от классической фразы: «но у меня же это работает!». Наш сервер непрерывной интеграции является «судьёй» или эталоном, по которому определяется работоспособность всего исходного кода. Каждый раз, когда кто-то сохраняет свои изменения в системе контроля версий, сервер непрерывной интеграции начинает собирать заново все доступные ему проекты и прогоняет все тесты на сервере. Если хоть что-то пойдёт не так, то сервер обязательно разошлёт всем участникам команды уведомления. Такие электронные письма содержат в себе информацию про то, какие именно изменения поломали сборку, ссылку на отчёты по тестам и т. д.

Каждую ночь сервер непрерывной интеграции пересобирает каждый проект заново и публикует на наш внутренний портал последние версии бинарников (EAR, WAR и т. д. [5]), документации, отчётов по тестам, по покрытию тестами, по зависимостям между модулями и библиотеками и ещё много чего полезного. Некоторые проекты также автоматически устанавливаются на тестовых серверах.

Чтобы это всё заработало, пришлось потратить уйму времени, но, поверьте мне, это того стоило.

Совместное владение кодом (Collective code ownership)

Мы выступаем за совместное владение кодом, хотя ещё не все наши команды внедрили у себя эту практику. На собственном опыте мы убедились, что парное программирование и постоянная смена пар автоматически увеличивают уровень совместного владения кодом. А команды, у которых совместное владение кодом на высоком уровне, доказали свою высочайшую надёжность. К примеру, они никогда не проваливают спринты из-за того, что у них кто-то заболел.

Информативное рабочее пространство