Уиттакер . - Как тестируют в Google

— Инструменты локализации.Их задача — постоянно переводить строки, специально выделенные разработчиками, чтобы локализованные версии наших продуктов выходили одновременно с англоязычными версиями.

— Метрики, графики и отчеты.Здесь речь об управлении багами по всем продуктам Google, сборе и хранении метрик разработки, тестирования и выпусков. Наша задача — предоставлять командам обратную связь, чтобы они могли улучшить свою работу.

— Значит, ты одновременно работаешь на всех фронтах. Чтобы достичь такого успеха, вы наверняка добавили много инноваций в рабочий процесс. Как вам удается сохранять баланс между новыми разработками и профильной работой? Ведь твоя команда не такая уж большая.

Ашиш:Все просто: мы не пытаемся взвалить на себя всю работу. Мы — централизованный отдел разработки инженерных инструментов. Команды часто разрабатывают специальные инструменты под свои задачи. Если какой-то инструмент начинают использовать и другие команды, мы оцениваем, можно ли включить его в общий инструментарий для всех сотрудников Google. Или, бывает, что мои инженеры сами предлагают какую-нибудь крутую штуку. Мы стараемся поддерживать все инициативы, но, конечно, у нас есть свои критерии для отбора инструментов перед тем, как сделать их централизованными. Первый критерий — инструмент должен потенциально сильно повлиять на производительность, второй — он должен быть полезен большому количеству разработчиков Google. В конце концов, мы работаем с общими инструментами, наше поле игры — это инструменты для широкой аудитории, которые полезны многим. Если инструмент полезен только одной команде — она сама им и занимается.

Мы много экспериментируем. Чтобы добиться большого успеха в следующем году, нужно работать уже сейчас, поэтому несколько небольших команд по одному-два человека всегда работают над экспериментами. Часто опыты проходят в «двадцатипроцентное» время, и я не против, так как это личное время инженеров, которым они вольны распоряжаться. Разумеется, часть экспериментов провалится, но те, которые приведут к успеху, с лихвой компенсируют любые неудачи. Мечтайте о большом, быстро понимайте, если идете не туда, и не сдавайтесь!

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

— А была ли идея, которая казалась тебе неудачной, но привела к успеху?

Ашиш:Да! Масштабная непрерывная интеграция. Она казалась недостижимой, потому что требовала огромного объема работы. Тогда у нас были тысячи машин, которые непрерывно выполняли циклы интеграции для каждого проекта. Кто-то предложил создать инфраструктуру, которая сделала бы этот процесс централизованным для всего Google. Такая инфраструктура опрашивала бы системы управления кодом на предмет изменений, держала бы в памяти огромный граф мультиязычных зависимостей этих изменений, а потом автоматически собирала бы и запускала нужные тесты. Многие скептически относились к проекту, так как идея была слишком масштабна и наши серверы могли не потянуть. Я тоже был среди скептиков: решение требовало огромного количества ресурсов. Но шаг за шагом наши инженеры понемногу преодолевали технические трудности до тех пор, пока не добились успеха: система запущена и работает. Собственно, это и есть схема нашей работы с проектами: начинаем с малого, а если практическая польза и потенциал доказаны, разворачиваемся на полную.

— А есть ли инструмент, который обещал быть успешным, но провалился?

Ашиш:Снова да! Удаленное парное программирование. В Google много распределенных команд. Многие команды применяют парное программирование и другие гибкие методы разработки. Часто бывает, что вы работаете над кодом, который написал человек из другого офиса, и если у вас появляются вопросы, то возникает задержка, влияющая на производительность.

Мы хотели построить плагин для удаленного парного программирования. Мы планировали написать инструмент, встроенный прямо в среду разработки, который бы давал возможность связаться с автором кода через Google Talk. В идеале автор кода получал доступ к рабочему пространству, и ребята могли править код вместе, наблюдая друг за другом по видео. Это парное программирование, только без присутствия.

К сожалению, опробовав тестовую версию только с простым совместным редактором без интеграции с Google Talk, мы свернули проект. Статистика использования не дала ожидаемых результатов, показала, что разработчики не заинтересованы в продукте. Может быть, мы переоценили важность проблемы.