Как eBay модернизировал самую важную страницу на нашей платформе

Фон

Страница eBay View Item находится в центре нашей платформы электронной коммерции. Наши клиенты загружают эту страницу более 250 миллионов раз в день, а жесткие ограничения на скорость и доступность сайта гарантируют качество их работы. И все же последний раз эта страница преднамеренно переписывалась десять лет назад.

Десятилетие быстрых итераций сделало кодовую базу все труднее поддерживать. Это мешает нам продолжать темпы инноваций, которых ожидают наши клиенты. На рис. 1 показан результат этого быстрого органического роста: устаревший стек, требующий дублирования работы для доставки на наши четыре платформы (настольный компьютер, мобильный Интернет, iOS и Android). Для нас было важно модернизировать эту систему и соответствующий процесс разработки, чтобы добиться прироста скорости, необходимого для продолжения инноваций для наших клиентов.

Цели

Наша основная цель состояла в том, чтобы постоянно открывать прирост скорости с первого дня, а не прилагать длительные усилия с большой отдачей в конце. Но как бы мы этого достигли?

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

Состояние проекта будет оцениваться по четырем ключевым показателям, изложенным в книге «Ускорение» Николь Форсгрен, Джез Хамбл и Джин Ким, с целями по улучшению (таблица 1). Ускорение используется в качестве ориентира для лидеров отрасли, стремящихся определить скорость.

Стратегия

Нам нужна была новая архитектура (рис. 2), которая устранила бы дублирование работы и выполнила бы все заявленные цели.

Нарисовать подобную диаграмму несложно, но реальный размер и область применения наших трех устаревших сервисов (монолитный сервис для настольных ПК, сервис с родным интерфейсом, веб-сервис для мобильных устройств) может привести к многолетним усилиям по созданию сервиса с эквивалентной функциональностью. под новую архитектуру. Проблема будет усугубляться постоянным внедрением новых функций (что делает разработку новой услуги похожей на попадание в движущуюся цель). Вместо этого мы разработали стратегию, позволяющую со временем выполнять полную миграцию небольших фрагментов кода (рис. 3). Наш план кристаллизовался следующим образом:

1. Внедрить новую услугу между уровнем данных и устаревшей системой.

2. Устаревшие службы передают свои данные через новую службу.

3. Реализуйте современные версии каждого модуля в новом сервисе и поместите их данные в проксируемый поток данных.

Исход

На момент написания этой статьи мы находимся на втором этапе, когда примерно 90 процентов модулей перенесены на новую архитектуру. Наша новая стратегия заключается в увеличении скорости разработки во всех областях View Item.

1. Все поддерживаемые платформы теперь получают одни и те же данные из одного сервиса, что на 1/3 убирает дублирование работы.

2. Помодульная миграция позволила нам получить 200-процентный прирост скорости в связанных новых функциях с самого начала проекта.

3. Опыт разработчиков

1. Новых членов команды легче адаптировать благодаря точной документации и современному стеку технологий, с которыми они уже знакомы.

2. Слияние кода происходит быстрее благодаря более быстрому конвейеру автоматизации.

3. Мы увеличили общую производительность за счет улучшения читабельности кода, документации и структуры проекта.

4. Все новые функции теперь пишутся только один раз и поддерживают сразу все четыре платформы.

Таблица 2 отражает соответствующие улучшения наших четырех ключевых показателей.

Кульминацией этих улучшений является 200-процентное увеличение скорости. Более того, мы увидели это увеличение сразу же на этапе миграции модулей проекта. Миграция каждого модуля, от самого первого до самого последнего, приводила к соответствующему увеличению скорости. Поскольку проект близится к завершению, мы уже на 50% сократили усилия (в днях) по усовершенствованию нового продукта.

Обучение

Миграция каждого модуля начиналась с глубокого погружения в соответствующий устаревший код. Из-за возраста кодовой базы в состав команд, ответственных за миграцию, больше не входят авторы исходного кода. Первоначально мы сосредоточились на создании исчерпывающей документации по устаревшей системе, чтобы помочь в разработке нового кода. Было быстро установлено, что этот процесс не дает ожидаемого результата; он устарел, когда мы обнаружили новые варианты использования. Был сделан поворот, чтобы сосредоточиться на быстром обзоре устаревших модулей для создания сводки высокого уровня. Затем мы полагались на обратный инжиниринг при создании новых модулей с исчерпывающей документацией только по новому коду, чтобы избежать того, чтобы будущие команды постигла та же участь.

Первые несколько модулей, подлежащих переносу, следовали целостному подходу, который пересматривал все части кода, взаимодействовавшие с ним, вплоть до включения уровня клиента и отображения. Такие изменения всегда проходят A/B-тестирование, чтобы убедиться, что качество обслуживания клиентов улучшилось. Данные по миграции некоторых модулей с изменениями UX показали негативное влияние на наших клиентов. Это стоило нам дополнительного времени на ожидание результатов тестирования и реализацию нового поворота функции для устранения этих недостатков. Самая важная вещь, которую мы узнали в начале проекта, заключалась в том, что нам нужно было полностью отделить модернизацию внутреннего кода от любых изменений поведения пользователя. Этот новый подход позволил нашим внутренним командам завершить все последующие миграции за более короткое время. Затем разработчики клиентов могли работать над независимыми графиками реализации, тестирования и итерации.

Главной темой этих уроков является гибкость. Мы культивировали командную культуру постоянного пересмотра наших решений и предположений. Итерация самого плана была самой важной частью гибкости в таком амбициозном проекте.

Заключение

Удвоение скорости команды — нетривиальная задача. Это требует тщательного планирования, исполнения и непоколебимой приверженности со стороны исполнительного руководства. Со всем этим наша замечательная команда смогла достичь поставленных целей. Проект продолжается уже два года, и сегодня он близок к финишной черте: выполнено более 90 процентов работ. Пошаговая стратегия позволила нам сразу разблокировать прирост скорости в начале процесса и постоянно разблокировать дальнейшие приросты в течение всей временной шкалы, не дожидаясь полного завершения проекта. Удвоение нашей скорости означает удвоение нашей способности оставаться лидером рынка, быстро реагируя на потребности наших клиентов.

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

Примечание. На момент публикации ведущего автора Лакшими Дурайвенкатеш больше нет на eBay.