Хабрахабр

Почему новый дизайн Gmail такой медленный?

image
Как известно, в 2018 году компания Google провела крупнейший редизайн интерфейса своего почтового сервиса Gmail. Как обычно, довольны им оказались далеко не все — и на этот раз есть вполне объективные причины для недовольства сервисом. Почему загрузка Gmail стала занимать так много времени, а действия вроде удаления или архивирования цепочки писем могут выполняться 4-6 секунд?

Пару дней назад подобным вопросом задался пользователь Hacker News — и он получил ответ от анонимного сотрудника Google, хлестко проехавшегося по культуре разработки внутри компании и своим коллегам.

С его слов, все это происходит в силу того, что в Google не предусмотрено никаких наказаний за подобные «промахи».

И то, что продукты могут содержать лишь половину необходимых фич, не работать, работать только из-под Chrome и прочее — это никого не волнует, ведь их создателям за это ничего не грозит. В стенах компании активно поощряют запуски (launch) — публичные релизы чего-либо. Вот мы и получаем в итоге сотни ненужных приложений-чатов, бесконечные редизайны и перезапуски — иначе отдельные личности не смогут получить повышение. Это — норма.
Смысл подобный действий заключается только в одном — в продвижении по службе, поскольку без крупных запусков дальше определенного уровня пройти не удастся.

Когда руководство компании попробовало решить проблему, выпустив внутренний документ, который вместо «launches» (запусков) мотивирует достигать успешных «landings» (посадок, успешных запусков) — всё, что изменили в своей жизни сотрудники, так это выполнили s/launch/landing/g в своих performance review.

На его разработку ушло два года, после чего компания решила приостановить разработку и заморозить проект. Возьмем, к примеру, мессенджер Allo. Как выясняется, отвечавшие за мессенджер люди при этом не пострадали — наоборот, некоторые из них даже получили повышение.

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

Бесконечно много. Знаете, сколько багов нужно пофиксить, чтобы получить повышение? Но достаточно запустить всего один редизайн — будь даже он практически бесполезен — и повышение у вас в кармане. Неважно, как много багов вы исправите — это никогда не принесет вам достаточного «вклада» для повышения, никогда.

Естественно, в стенах самой компании есть люди, которые предупреждают о возможности подобного и жалуются, заносят баги производительности в трекеры — вот только все это игнорируется; большинство работников со временем сдается и перестает писать про баги, ведь типичным ответом им будет «вы не наша целевая аудитория».

Все мы! И мы все знаем об этих проблемах! Некоторые увольняются, когда до них это доходит; другие просто начинают «оптимизацию» в сторону повышения — вместо того, чтобы оптимизировать в сторону того, что будет хорошо для пользователя или для компании.

В своих мыслях разработчик не одинок. Грэхем Уилер поделился историей из своей жизни в Google, подтверждающей его позицию.

Я решил, что лучшим способом потратить мое время будет произвести рефакторинг кода, который мне достался, чтобы довести степень его покрытия тестами с 0% до 80%, попутно исправив немало багов. Однажды в Google я получил негативный performance review. В итоге я получил на performance review дерьмовый отзыв, а автор оригинального говнокода — повышение.

Рассказы о проблемах управления разработкой в стенах Google появляются в Сети регулярно. Реакция пользователей тоже не заставляет себя ждать. Бизнес-клиенты, использующие Google Apps, переходят на FastMail, основной принцип которого — только электронная почта и ничего лишнего.

Который, с одной стороны, заполучил редизайн в духе Material Design, оффлайн-режим и множество других мелких улучшений, которые переносят в него из Google Inbox, который со следующего года прикажет долго жить. Примерно так мы с вами и получаем вещи вроде нового Gmail. 3MB. С другой — для полной загрузки выполняет 358 запросов и выкачивает 6. 3KB, что позволяло ему загружаться за 2 секунды. Для сравнения, «древний» режим HTML View в Gmail — это всего лишь 14 запросов и 25.

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

Стив по большей части занимался тем, что исправлял баги во всех основных фреймворках ОС — и по итогам выпуска ему было отказано в повышении из-за того, что его присутствие «не было критически важным ни на одном из проектов». Похожую историю рассказал разработчик Стив, работавший в Apple над MacOS X Snow Leopard.

Однако, в то время как одни ожидаемо работали над стабильностью, другие активно «пропихивали» в релиз новые фичи вроде сборщика мусора для Objective-C, чем задержали работу остальных и сделали XCode неюзабельным на несколько месяцев. Ирония здесь заключается в том, что данная версия ОС по идее руководства компании должна была стать релизом, в котором все было направлено на улучшение стабильности и производительности системы (у автора этих строк до сих пор сохранились).

Зато работа над ошибками не прошла даром для простых пользователей, которым запомнились отличная работоспособность Snow Leopard и последовавшей за ней Lion — в отличие от Chrome, который только за время написания этого поста успел пару раз зависнуть и вызвать «крэш» вкладки с черновиком.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть