Джеймс Уиттакер - Как тестируют в Google

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

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

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

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

— Твой совет компании, которая хочет построить непрерывный процесс автоматизации? С каких инструментов стоит начать?

Ашиш:Самое важное — создать такую среду разработки, чтобы в ней даже разработчик-новичок смог работать с вашей командой. Должно быть невероятно просто взять код из репозитория, отредактировать, протестировать, отладить его и опубликовать. Если вы сформируете настолько удобную среду, то все ваши разработчики будут работать более продуктивно и вы сможете выпускать ваше ПО без задержек.

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

— Какие инженеры нужны в твоей команде? Вряд ли любой разработчик сможет разрабатывать инструменты?

Ашиш:Разработка инструментов предполагает особую любовь к компьютерным наукам. Я говорю о разработке языков и компиляторов, системном программировании и т.д. Мне нужны такие инженеры, которые воспринимают разработчиков как потенциальных пользователей и ловят кайф от того, что их инструменты помогают другим разработчикам приносить больше пользы.

— Раз уж мы заговорили о пользователях, как ты убеждаешь людей применять твои инструменты?

Ашиш:Разработчики Google — это очень благодарные пользователи. Раз в неделю мы проводим встречи и демонстрируем наши инструменты. Инженеры приходят, задают вопросы, и если инструмент решает их задачи, они берут его на пробу. На инструменты, которые решают насущные проблемы, довольно большой спрос. Чем ближе к реальности, тем эффективнее. Надо быстро отказываться от проектов, которые нерезультативны или не востребованы.

— А тебе когда-нибудь попадались инструменты, которые только мешали работе или приносили больше вреда, чем пользы?

Ашиш:Да, но я даже не запоминаю их, так как все подобные проекты очень быстро забрасываются. Цель разработки инструментов — автоматизация процесса и его упрощение. Не нужно автоматизировать неправильные решения. Если разработчик совершает ошибку, зачем упрощать ему этот процесс? Отступите на шаг и оцените: может быть, нужно заняться чем-то более полезным.

— Над чем сейчас работаешь? Какие новые инструменты готовит твоя команда?

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