Делаем TDD привычкой: проблемы и внедрение

Я столкнулся с командами в нашей организации, которые пытаются внедрить Test Driven Development (TDD).Иногда одному или двум разработчикам удается применить его без посторонней помощи, но у большинства этого не выходит. Чтобы лучше понять проблему я провел опрос среди членов команды и обнаружили, что даже после обучения еще многое предстоит сделать. Эта стратегия была разработана, чтобы помочь любому внедрить TDD в организации, хотя некоторые из идей применимы лишь для средних и крупных компаний.

Мое исследование членов команды (все они прошли обучение) показало следующие проблемы:

• Люди с трудом использубт TDD сам по себе, когда они не имеют большого опыта работы с ним.
• В обучение TDD используются упрощенные примеры, в отличие от реальных систем.
• Требуется больше времени, чтобы экспериментировать и пробовать без обычного давления со стороны менеджмента, который требует выпускать ПО регулярно.
• Существуют языки, используемые в реальном мире, такие как Visual Basic и JavaScript, которые никогда не используются в качестве примеров.
• Типичный проект полон унаследованного кода, при этом не было объяснено, как улучшить этот код.
• И как всегда нет времени на учебу — нужно выпускать продукт.

Основные проблемы

Исходя их этих симптомов, что же является основными проблемами?

Test Driven Development трудно изучать. Фазы обучения (время, в течение которого он становится глубоко укоренившейся привычкой) обычно длится от двух до четырех месяцев, в течение которых производительность снижается. В конечном счете, преимущества будут очевидны и TDD будет использоваться само по себе, но вопрос в том, как сделать так, чтобы это время появилось? Многие разработчики сдаются уже через несколько дней.

Большинство стратегий внедрения, которые я видел, делают акцент на аудиторные занятия (или электронного обучения) и наставничество один-на-один. Хорошо проведенные, они конечно достигают своей цели, но я думаю, что требуется гораздо больше.

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

Интерактивное обучение имеет преимущество, позволяя погрузиться в тему глубоко.Однако все еще не достаточно шансов попробовать все это на практике. Кроме того, эти курсы, как правило, проходят без взаимодействия с другими студентами. Услышав вопросы от своих одноклассников и коллег, вы часто можете сами достигнуть понимания.

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

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

И наконец: унаследованный код делает и без того трудную задачу сложнее в сотни раз. Разработчики справедливо задают вопрос: «Как я могу протестировать эти тесно связанные объектов? Этот код сложный, как я могу проверить этот алгоритм? „

Один из подходов

Что же может сработать? Предыдущие подходов страдают от двух ключевых проблем: отсутствием глубины и общения. Полная стратегия содержит в себе комбинацию подходов.

• Обучение в классах — Разработчикам нужно введение в TDD, и занятия в классе по-прежнему является лучшим вариантом для большинства людей.Хитрость заключается в том, чтобы понять, что обучение само по себе не приведет людей к TDD.
• Online Training — это поможет закрепить основные идеи.Кстати, если и есть необязательный шаг в ходе обучения, то это он и есть.
• Терпение — это займет больше времени, чем вы планировали.
• Метрики — с помощью инструментов покрытия кода (например, Emma, Cobetura, NCover, …) и объяснения членам команды, что измерение будет лишь одним способом сказать, что дела вещи пошли лучше или хуже.Очевидно, что это не измеряет качество тестирования и результат должны быть приняты с недоверием.
• Внушать гордость — Разработчики должны знать, как выглядит чистый и простой код и тесты, и они должны чувствовать, что это стоит того, чтобы напрягаться. Боб Мартин только что написал книгу под названием “Чистый код», которая на хорошо про это рассказывает.
• Менеджмент — Разработчикам нужно четкое заявление от руководства, что они понимают, что переход к TDD потребует времени и замедлит команду. Им нужно, чтобы было ясно, что ценится качество по сравнению со скоростью и накоплением технических долга. Большинство разработчиков находятся давлением, чтобы производить, производить и производить «полезный» код.Управленцам, вероятно, придется повторять это утверждение более чем один раз. Чем выше уровень в организации, от которого это заявление исходит, тем больше люди будут слушать.
• Парное программирование — если вы застряли и не знаете, куда идти дальше партнер может часто помочь, даже работы с другим новичком может быть хорошим началом.
• Сообщество — Создание сообщества в вашей организацией (или городе) с целью обмена опытом.Место для общения с другими людьми, которые учатся применять TDD, учатся друг у друга чужим успехи и ошибки.Место, чтобы помочь вырасти культуру необходимую для TDD. Возможность поделиться новыми идеями.
• Coding Dojo — Место для практики решения небольшой проблемы вместе.Это безопасная среда совместной работы с акцентом на изучение проблемы в группе и не обязательно ее решения.
• Чтение семинаров — группа не более восьми человек собираются на регулярной основе, чтобы обсудить главу из книги.
• Периодические визиты тренера — могут помочь команде вернуться на правильный путь, когда они сошли с пути и прекратили практиковать TDD. В этих случаях, простая паре с одним или двумя людьми может помочь вновь заразить всю команду.

В основе этого плана лежит: создание постоянного обзения и расширения сотрудничества вокруг TDD. Три из этих стратегий сосредоточены в этой области: парное программирование, Coding Dojo и чтения семинаров.

Coding Dojo

Coding Dojo (с помощью формата Рандори) является мероприятием, где небольшая группа людей (не более 15), решает задачи с использованием TDD (адаптировано из Danilo Sato):

• Работа выполняется на одном компьютере с проектором
• Кодирование выполняется в парах
• Один из членов пары переключается каждые 5-10 минут (у нас все отлично сработало для 7 минут).
• Разработчики должны объяснять, что они делают, так чтобы зрители понимают, что происходит «на клавиатуре».
• Зрители должны комментировать только дизайн, в случае когда тесты пройдены чисто.Когда тест завален, они должны задавать вопросы.
• Если аудитория находится в замешательстве, то работа останавливается и разработчики должны объяснить, что происходит.

Из опыта я рекомендую вам выбрать для начала очень небольшие задачи.

Чтение семинаров

Для чтения семинаров существует целый ряд книг:

• для проектов на Java: Lasse Koskela’s Test Driven: TDD and Acceptance TDD for Java Developers;
• для проектов на .NET: Kent Beck’s Test Driven Development: By Example;
• более подробно про паттерны unit-тестирования Gerard Meszaros xUnit Test Patterns: Refactoring Test Code
• и если ваш код не был разработан с TDD: Michael Fethers Working Effectively with Legacy Code.

Обычно команды обрабатывают 1-2 главы за сессию. Темп достаточно медленный для того, чтобы люди могли читать вне работы. Кроме того, он дает достаточно времени для углубленного обсуждения нескольких пунктов из этой главы.

Преимущества совместного обучения

На семинарах должна быть пицца (или любая другая еда) — так как вы просите людей тратить свое личное время для того, чтобы делать что-то похожее на работу, то им нужен стимул. Два семинара могут чередоваться, так что люди не чувствуют, что они застрял в чем-то одном. И не следует ожидать, что группа будет постоянной от встречи к встрече.

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

Делаем TDD привычкой

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

• Терпение, практика, глубина
• Поддержка менеджмента
• Многосторонний подход
• Разработчики помогают разработчикам