В маленьком стартапе изменить поведение команды относительно легко. Вы можете сесть с командой за один стол, обсудить новую модель работы, а затем всё реализовать. А когда у вас десятки инженеров, разбросанных по разным проектам, трансформация потребует более тщательной стратегии. Один из подходов заключается в управлении процессом через прямые приказы «иди и сделай», однако в условиях относительной самостоятельности сотрудников, присущих многим стартапам, такой подход плохо работает. Другой способ заключается в том, чтобы лично подавать пример и указывать направление развития.
С первых дней в Airbnb происходило то, что случалось со многими стартапами: мы писали много сомнительного кода и мало времени уделяли тестированию. И чем больше мы росли, тем большей это становилось проблемой. На сегодняшний день мы ежедневно обрабатываем данные миллионов пользователей. Только представьте себе, с какими объёмами данных приходится иметь дело, учитывая одни только платежи, когда сделки ежеминутно происходят в десятках разных валют. Небольшая незначительная ошибка может иметь огромные последствия для наших пользователей. Теперь благодаря нашим тестам, мы можем быть уверены, что финальный продукт выйдет действительно качественным.
Мы расскажем вам, как нам удалось изменить культуру тестирования и какие инструменты мы использовали для написания и выполнения тестов, чтобы упростить жизнь нашей команде.
Для нас новая культура тестирования началась с pull request'ов («запросов на включение изменений»). Однажды несколько сотрудников решили рассказывать другим с помощью pull request'ов о тех изменениях, которые были сделаны. Это не стало обязательной практикой, но со временем повлекло за собой ряд качественных изменений: во-первых, выросло качество кода, во-вторых, это стало считаться попросту старомодным.
Этому способствовал и рост команды – каждый новый инженер был проинформирован о важности peer reviews (далее – PR), процент использования PR в командах рос, вне зависимости от того, переходила ли «старая гвардия» на новую модель работы или нет. В итоге, даже «старички» стали чувствовать себя неловко, внося изменения напрямую в мастер.
Мы стали заботиться о тестировании, активно продвигали методологию разработки через тестирование (Test-Driven development, TDD) и следовали трём законам TDD:
1. Новый рабочий код пишется только после того, как будет написан «падающий» модульный тест.
2. Вы пишете ровно такой объем кода модульного теста, какой необходим для того, чтобы этот тест «падал» или код не компилировался
3. Вы пишете ровно такой объем рабочего кода, какой необходим для прохождения «падающего» модульного теста.
Спустя год удалось добиться значительного прогресса. Мы начинали с нескольких слабых тестов, а пришли к большому комплекту. Самое главное, мы ушли от порочной практики, при которой большая часть нового кода сдавалась вообще без единого теста. Мы не только стали командой, которая поверила в тесты, но стали теми, кто действительно их пишет.
Использование PR даёт ряд преимуществ: у нас появилась площадка для обсуждения структуры кода и архитектурных решений, увеличилась вероятность того, что опечатки и логические ошибки будет найдены прежде чем они достигнут пользователей. PR позволяет всем членам команды лучше понимать, над чем мы собственно работаем и, в свою очередь, ведёт к дальнейшей трансформации всей культуры тестирования.
В Airbnb была установлена базовая среда тестирования Rails. Копия приложений на «рельсах» хранилась внутри директории /spec. Тестирование запускалось довольно медленно, а большинство сотрудников не знали, как организовать тестирование в собственной локальной директории. Новые сотрудники соглашались, что тестирование имеет крайне важно значение, но когда они видели, что никто не обращает внимания на тесты, они быстро о них забывали. Было понятно, что необходимо внести серьезные коррективы в стратегию тестирования.
Во-первых, нам нужен был урок по развёртыванию PR, включая конкретные примеры работы, будь то тестирование новой функции, исправление ошибок или рефакторинг. Во-вторых, мы должны были начать воспитывать команду, устраивать встречи инженеров, показывать товарищам по команде, как писать тесты. Приветствовались обмен ссылок и рекомендации по обучающей литературе. Так в компании появился еженедельный информационный бюллетень с новостями тестирования, демонстрацией хорошо написанных спецификаций и объяснением основных моментов PR.
В-третьих, мы должны были использовать наше развитие как инструмент превращения сотрудников в настоящих чемпионов тестирования. Этот вопрос решается «на словах», подчёркивая важность тестирования на примере того прогресса, что уже был достигнут. Когда объёмы тестирования увеличился, другие сотрудники по инерции включились в процесс и стали считать тесты само собой разумеющимся.
Очевидно, все эти изменения ничего бы не стоили, если бы написание и выполнение тестов стало слишком болезненной и тяжёлой процедурой. В следующем разделе мы увидим, как нам удалось сделать «культурный сдвиг» менее тяжёлым для сотрудников.
Нам нужно было иметь простую и быструю среду тестирования, поэтому мы выбрали Vagrant. Эта утилита позволяет создавать и настраивать виртуальную среду разработки и поддерживает несколько систем виртуализации прямо из коробки. В связке с Chef — утилиты для управления конфигурациями и многого другого – можно использовать для создания VirtualHost и папок нового проекта. Нам нравится скорость работы такого решения, а большая часть людей в нашей команде использует и Zeus, который заранее загружает приложение на Rails, чтобы ускорить его старт. Vagrant и Zeus имеют свои проблемы, но на практике мы обнаружили, что они экономят огромное количество времени.
Есть множество отличных решений для ускорения Rails, но учитывая размер нашей базы кода и скорость, с которой идёт развитие, большинство из них не возможно было применить незамедлительно. Мы нуждались в такой системе сборки, которая позволила бы нам в режиме реального времени распараллелить наши тесты. Наша команда использовала несколько различных решений, прежде чем остановиться на Solano. У каждой из предыдущих систем были выявлены некоторые проблемы: нестабильность, проблемы с памятью, плохое распараллеливание, «страшный» веб-интерфейс и т.д. Solano поддерживает тестирование в несколько потоков, запуская их параллельно, а затем собирая результаты. У продукта впечатляющая производительность, отличный веб-интерфейс, есть поддержка командой строки. После начало его использования количество воплей и страдальческих гифок от разочарованных инженеров стало рекордно низким.
Внедрение непрерывной интеграции (после каждого коммита) стало огромным первым шагом, однако мы все хотели, чтобы наше тестирование шло идеально. Реальность автоматизированного тестирования показала, что нужны компромиссы в чистоте тестирования. Это нормально. Важно, чтобы тестирование шло всё время. Даже когда трудно. Особенно, когда это трудно.
С ростом Airbnb мы начали добавлять в сервис намного больше критически важных функций. Очевидно, что есть еще много возможностей для совершенствования автоматизированного тестирования, но сейчас мы довольны полученным результатом. Мы никогда бы не смогли добиться этого без усилий, проявленных «снизу», и эти усилия оказались бы тщетными, если бы не были объединены в единой стратегию улучшения инструментария тестирования. Все инициативы, в сочетании с образовательной программой, привели нас к точке, где тестирование повсеместно и относительно безболезненно для системы. Фокус в том, что вам нужна команда, открытая идее выработать хорошие привычки при тестировании.
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий