Небольшой дисклеймер: мы приложили видео докладов и сделали краткое описание каждого из них. В тексте будет некоторое расхождение в стиле изложения и порядке фактов по сравнению с записью. Зато комментарии нашего судьи подчеркнут интересные места выступлений. Поэтому после статьи посмотрите видео и насладитесь полной картиной этого замечательного матча.

А теперь давайте поговорим с тренерами.

Наши бойцы давно готовились к этому матчу. Тренировочный процесс построен максимально эффективно: в каждой команде по 10–12 человек, которые работают над 40 проектами. План тренировок выстроен по схеме 80/20. Разработка новых фич занимает 80–85 % времени, поддержка — всё остальное. Не буду нахваливать ребят перед матчем, чтобы не сглазить, лучше расскажу о недавних успехах. Один наш бэкендер ускорил работу приложения на 30 % благодаря оптимизации запросов в базе данных.

В арсенале моих ребят секретные приёмы из Python, C# и Go. На месте противника я бы сразу сдался!

Технологический стек построен в основном на open source, и такой подход выгоден для бизнеса. У нас нет чёрного списка инструментов, зато есть перечень того, что можно использовать. Никто не запрещает вносить свои инициативы и предлагать новые фреймворки и инструменты. Если они действительно подойдут для наших задач, мы внесём их в стек используемых технологий.

Для отработки идей и построения MVP используем Django; он хорошо подходит для этих целей. Но в продакшене мы применяем другие фреймворки.

В отделе очень гордятся разработкой приложения для сотрудников компании «Мобильное рабочее место сотрудника торговой сети „Перекрёсток“». Наши спецы понимают: приложения, которые мы создаём, делают проще и удобнее жизнь миллионов людей, и для нас это главный источник вдохновения.

Ребята постоянно находят интересные решения или разрабатывают новые полезные инструменты. Поэтому примерно раз в месяц-полтора мы проводим внутренние митапы, где инициативные разработчики делятся своими идеями.

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

А если человек успешно справляется с текущими обязанностями и просто хочет спокойно работать, мы даём ему такую возможность.

Хотя другая сторона пытается запугать нас, мы не поддадимся на эти угрозы. Наш отряд состоит из 60 лучших атлетов кода. Они в совершенстве владеют Java, Scala и Kotlin, и уж поверьте, тут мало никому не покажется. В каждой команде у нас несколько фронтендеров, бэкендеров, аналитиков, а также SRE-инженер, QA-специалист и деливери-менеджер или руководитель. Если команда работает с большими данными, то в ней также присутствуют Data Analyst, Data Quality Analyst и Data Scientist. Эти бригады работают быстро, слаженно и чисто.

И у нас есть чем ответить на успехи фронтендеров! На проекте «X5.Транспорт» мои ребята помогают обрабатывать десятки гигабайт информации в онлайне. Поверьте, это лютая тренировка!

Отдел состоит из нескольких продуктовых команд, причём один разработчик может быть привязан сразу к нескольким продуктам. В отделе много талантливых сотрудников, которые при необходимости могут делать фронт/фулстеки.

Перечень основных проектов:

Самые интересные с точки зрения Java-бэкендеров проекты:

Мы противники переработок, так как считаем, что при грамотном планировании проектов беспокоить специалистов в нерабочее время не потребуется. Мы стали «челенджить» необходимость каждой переработки, и вскоре их количество сократилось. У ребят восстановился нормальный баланс между работой и личной жизнью. К нашему удивлению, настроение некоторых разработчиков упало. У них стали происходить периодические конфликты с менеджером. Созвонились, разобрались: оказалось, что ребята добровольно соглашались на переработку, чтобы заработать себе, например, на новогодний подарок. Мы решили направить этот процесс в благое русло и создали биржу задач для Java-разработчиков (подсмотрели эту идею у наших DevOps-инженеров). Теперь любой специалист может брать с этой биржи дополнительные задачи, работать над ними в свободное время и получать бонусы к зарплате.

Итак, мы узнали о подготовке. А теперь в бой!

Разработку ПО можно разбить на разные составляющие, но среди них есть два критичных элемента: статическая (предметная) область и динамическая (непосредственно разработка). С этими же сторонами командной работы мы сталкиваемся и в любой другой сфере повседневной жизни.

— Георгий начинает выступление с запрещённого приёма, рассказав про сломанную руку своего друга. Это же настоящий берсерк! Посмотрите, как он захватывает внимание слушателей и не оставляет ни единого шанса проспать этот доклад!

Допустим, вы затеяли в квартире ремонт, наняли нескольких мастеров и попросили их «сделать красиво». Вот только «красиво» в представлении каждого из них окажется своё. В результате квартира будет выглядеть как угодно, но только не так, как вы рассчитывали. Но если перед наймом работников вы закажете у хорошего специалиста дизайн-проект, то вам останется только передать этот чёткий план действий мастерам — и ожидать от них воплощения заранее известного результата.

Программисты — мастера по разработке ПО — тоже должны получить такой «дизайн-проект», формирующий у них общее видение продукта. Без него их действия будут несогласованны, а разработка — обречена на провал или, по крайней мере, более долгий и тернистый путь к реализации.

Давайте посмотрим, какими способами можно донести это общее видение до разработчиков.

Предметная область проекта, выражаемая единицами языка (словами и понятиями), должна трактоваться всеми участниками разработки единообразно. А значит, нужно составить перечень используемых терминов и определений. Эти термины образуют определённую иерархию, поэтому в результате получится не просто глоссарий в виде списка, а диаграмма со связями (например, ER-диаграмма проекта базы данных). На её основе гораздо проще создавать чёткие модели и обсуждать их, не сомневаясь, что мы говорим друг с другом на одном языке.

Одна команда проектировала системы для ретейла, оперируя следующими понятиями:

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

А ещё глоссарий проекта был избыточным: на самом деле товар — это и есть айтем, а стек — партия. Вместо четырёх понятий достаточно было всего двух.

После того как команды согласовали единый глоссарий предметной области, у участников разработки улучшилось понимание вообще всех задач. Им больше не нужно было, переключаясь с доработки одного модуля статистики на работу над другим, «нырять» из одной предметной среды в другую: теперь во всех составляющих проекта были одни и те же чёткие, однозначные определения.

Глоссарий был составлен путём выделения доменов, каждый из которых объединял схожие по поведению сущности. В результате получился пакет с файлом __init__.py, содержащим описание и краткую характеристику домена, а также ссылки на документацию, а в переменной __all__ был приведён перечень всех методов, доступных для взаимодействия с этим пакетом.

Если любому из тридцати человек, работающих над проектом, потребуется перейти из одной области разработки в другую, в которой у него пока нет точного представления обо всех доступных функциях, методах и сигнатуре модуля, всё, что ему требуется сделать, — это ознакомиться с кратким содержанием __init__.py.

А ещё выделение доменов и чёткое описание функций пригодилось, когда проекты стали масштабироваться. Видение общей системы, в которой каждый домен взаимодействует с другими через общий интерфейс, сильно упростило работу над оптимизацией.

Разработчики любят писать код, но обычно не горят желанием его документировать. Чёткое описание алгоритмов — скучное и трудоёмкое занятие. Да и кому вообще может понадобиться вся эта документация? Но со временем объём кода разрастётся, и, чтобы разобраться в нём, не имея под рукой описания процессов и механизмов их взаимодействия, потребуется не одна неделя.

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

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

Горы документации для проекта по разработке ПО не нужны: достаточно всего лишь составить чёткий глоссарий предметной области и диаграмму бизнес-процессов. Это позволит всем участникам команды найти общий язык и работать более продуктивно. А правильная декомпозиция работ делает задачу понятной даже для тех, кто не знает языков программирования.

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

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

Начав работать с большими системами, вы поймёте, что даже к простым задачам требования тут совершенно другие. Многое из того, что для вас привычно, старшие разработчики назовут неприемлемым и доходчиво, с примерами, объяснят, почему это так. Пугаться этих трудностей не стоит: если вы примете их как вызов, то вскоре начнёте расти во всех аспектах:

Допустим, разработчик на собеседовании показал хорошие знания ядра Java и дал понять, что готов развиваться, хоть у него пока и нет широких познаний в сфере различных enterprise-библиотек.

Десять лет назад в подразделении развития магазинных систем X5 Group работало примерно 20–30 человек. У компании была небольшая самописная система, которая автоматизировала работу магазинов. Она была завязана на ОС Windows и поддерживала небольшой список вендоров магазинного оборудования. Эти недостатки не позволяли быстро расти и открывать новые точки.

При открытии нового магазина важную роль играет стоимость этого процесса. Чем она ниже, тем быстрее будет развиваться бизнес. Топ-менеджмент поставил перед командой задачу: снизить стоимость открытия новых точек. Работники изучили рынок, купили одну из коробочных магазинных систем на замену прежней и начали над ней работать. В итоге с 2014 по 2019 год доля рынка, которую занимает X5 Retail Group, выросла в два раза: с 6% до 12 %.

— Десять лет в компании! Вы представляете, какой опыт накопил Андрей? Да он может в памяти прокрутить всю историю версий кода, от первых магазинов до всероссийской сети! Серьёзный вызов фронтенду!

Со временем количество функционала, который нужно было создать и внедрить, выросло настолько, что возможности развития приобретённой системы достигли своего потолка. Тогда разработчики из X5 решили изменить её монолитную архитектуру и создали множество микросервисов.

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

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

Теперь микрофон уходит другой стороне — фронтендерам. Поговорим с тренером и посмотрим на их технику.

В отделе преобладает матричная структура: как и у бэкендеров, люди распределены по разным проектам, причём один разработчик может быть привязан сразу к нескольким. Если в одной команде программист чувствует себя некомфортно, он может спокойно перейти в другую. В этом плане у нас полная свобода. Главное, чтобы задачи выполнялись.

Большинство сотрудников работает над новыми проектами, так как продуктам, которые уже запущены и находятся в эксплуатации, требуется минимум поддержки (самое серьёзное, что приходится делать, это исправлять иногда отдельные баги).

У нас нет команд, состоящих из одних только фронтендеров. Они всегда работают в связке с бэкендерами, тестировщиками и аналитиками, при этом в любой команде фронтендеров как минимум двое.

В компании есть замечательная традиция: программисты от любого направления могут стать кандидатами на звание «сотрудник квартала». Победители смогут прийти на общий завтрак с топ-менеджерами компании или даже с директором правления в X5 Tech — Антоном Мироненковым.

После найма новый сотрудник проходит испытательный срок. Это позволяет выявить его сильные стороны: если разработчик не справился с поставленной задачей, но проявил себя в чём-то ещё, мы можем дать ему работу из другого направления.

В отделе очень гордятся инициативами компании, такими как «Природа кода».

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

Итак, раунд!

«Ассортимент Пятёрочка» — это приложение с технологией GraphQL (API создан на основе Apollo Server), с помощью которого продавцы решают, как эффективнее расставить товар. На 17 тыс. магазинов приходится 4 тыс. наименований товаров, и у каждого товара может быть до 100 колонок с различными параметрами, поэтому требования к приложению довольно высоки.

— Перед нами добряк и весельчак, но попробуйте не посмеяться над его шутками, он вам покажет! Цифры в начале доклада действительно угрожающие. Посмотрим, как фронтендеры со всем этим справились.

Технология GraphQL обладает целым рядом преимуществ:

Но всё же есть GraphQL и недостатки, которые могут сделать разработку затруднительной:

Каждый разработчик сам может оценить, что перевесит в случае с его проектом: достоинства GraphQL или его недостатки. Команда X5 для себя решила, что будет и дальше использовать эту систему, так как широкий выбор инструментов делает её достаточно гибкой для их сферы разработки.

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

Давайте посмотрим, что бывает, когда руководство требует совместить скорость и функциональность, на примере оптимизации сайта vprok.ru.

Для анализа эффективности оптимизации использовался общепринятый параметр Google PageSpeed (GPS); удовлетворительным считается результат не ниже 50 баллов.

Для начала нужно было определить, какие элементы на странице самые тяжёлые. Ими оказались картинки с изображением товаров, и было решено сделать их загружаемыми через AJAX-запросы. Но в результате вырос размер JS-скриптов, обеспечивающих эти постлоадеры.

Детальное изучение гугловских алгоритмов определения скорости сайта показало, что есть две основополагающие метрики: First Contentful Paint (FCP; время отрисовки первого контент-значимого элемента) и Largest Contentful Paint (LCP; время отрисовки самого большого элемента контента).

Самым большим элементом контента была тяжёлая картинка с товаром, и после первого этапа оптимизации время её загрузки увеличилось, потому что мы все картинки загружаем после загрузки каркаса страницы. Было принято решение отделить первую картинку и отдавать её вместе с HTML-кодом, генерируемым на сервере. И уже после того, как браузер увидит большую картинку, к ней дорисовывается остальная галерея товара. В качестве бэкенда сайта на сервере используется Laravel. Результат этой оптимизации обрадовал: 55 баллов GPS.

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

К тому же сейчас отдел маркетинга убрал с сайта большой баннер, и самым тяжёлым элементом оказался скрипт принятия cookies. А значит, цель ещё не достигнута и нужно принимать дальнейшие меры по оптимизации.

Знаете, друзья, сначала я был скептически настроен по отношению к этому батлу. Ну честно: кому придёт в голову сравнивать такие разные сферы разработки? Но когда я послушал все доклады, то понял, что бойцы из обеих команд освоили множество сложных и разнообразных навыков, которые действительно можно сравнить. Так кто же победил? Возможно, бэкендеры исторически закрепились в сознании как более опасные мастера боевых искусств, чем фронтендеры. Ещё бы: Java, Python, Go, C#, highload, Big Data — как угрожающе это всё звучит!

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

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

Как же сложно выбрать победителя! А впрочем, предлагаем решить это читателям Хабра. Кто выступил артистичнее: фронтенд-отдел X5 или бэкенд?