Хабрахабр

Зачем нам в «Леруа Мерлен» нужен собственный российский отдел разработки на 200 человек

Привет! Я Валерий Лаптев, руководитель разработки LM в России. За два года мне нужно было поднять огромный отдел, и это был довольно интересный опыт.

Головная компания — во Франции, называется ADEO. Дело в том, что «Леруа Мерлен» есть во многих странах. Бизнес-модели у нас разные: если на российском рынке мы держим минимальные цены (ниже всех конкурентов в мониторинге), то в Европе всё иначе. Там пишут код под Францию, Италию, Испанию и Россию. Есть особенности инфраструктуры России (те же очень большие задержки до Хабаровска) и другой жизненный цикл оформления заказа. На самом деле отличий море — начиная от особенностей локали и заканчивая другим законодательством. Всё это порождает вот такой адский код, состоящий из огромных блоков IF:

Накатывались они примерно за полгода и не всегда правильно. Два года назад у нас было 60 магазинов и много-много хотелок по фичам. Это нужно было для особенностей доставки в России, поскольку страна больше других стран присутствия LM. Последней каплей после кучи отклонённых по низкому приоритету фич была просьба завести в заказ поле-строку, чтобы мы его уже потом сами парсили. Нам отказали и в этом, точнее, сказали, что будет где-то через семь-восемь месяцев.

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

Почему фичи реализовывались медленно?

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

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

У тебя ТЗ — написать главу как Наташа Ростова гуляла под дождём по парку. Программист: Ну представь, что ты писатель и поддерживаешь проект «Война и мир». Почему умерла? Ты пишешь — «шёл дождь», сохраняешь, вылетает сообщение об ошибке: «Наташа Ростова умерла, продолжение невозможно». Выясняется, что у Пьера Безухова скользкие туфли, он упал, его пистолет ударился о землю и выстрелил в столб, а пуля от столба отрикошетила в Наташу. Начинаешь разбираться. Зарядить пистолет холостыми? Что делать? Решили убрать столб. Поменять туфли? Выясняется, что он в следующей главе облокачивается о столб, которого уже нет... Получаем сообщение: «Поручик Ржевский умер».

В общем, когда у нас внедряется что-то для российских касс, где-то в Бразилии у кого-то может отрикошетить.

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

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

Решение проблемы

Первый подход был в лоб: мы предложили открыть нам код, чтобы делать туда пулл-реквесты. Предполагалось, что тут будет сидеть человек 10 разработчиков, которые быстро-быстро будут кодить бизнес-критичные функции, отдавать французам, те — тестировать по своей процедуре, и всё будет хорошо.

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

Приняли наше предложение про одну ветку для опытов. Французы в ADEO хотели релизный цикл за накатку и установку новых версий через себя.

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

Мы сидели шесть месяцев без релиза. Потом шесть месяцев не выходила важная нам фича в контентной части (управление данными о товаре, которые видит клиент). В итоге долго сидели на ключевой системе без обновлений. То у них фича не шла, то тесты не прошли, то реализовали не совсем то, что нам нужно. В коде из-за ряда археологических слоёв встретили вещи вроде неверного использования SQL-базы и нереляционной базы. Там были NodeJS + PostgreSQL + Couchbase + Elasticsearch + Angular на фронте. На одну страницу сайта с показом товара приходились десятки и сотни таких запросов. В одном из мест брался огромный кусок мастер-данных, вставлялся в одно поле SQL-базы, а потом в NoSQL-базе разбивался на сущности. Мы поняли, с какими особенностями наслоений легаси сталкивается головной отдел. При дальнейшем чтении этого легаси волосы на разных частях тела начали шевелиться.

Собственная разработка

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

Всё равно всё было очень медленно. Не работало.

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

А для этого стали переключать часть сервисов на то, что могло бы быть сделано у нас. То есть мы планировали переписать целые блоки логики в виде своего кода. Тогда мы полностью следовали стеку головной компании — Java, Spring и всё рядом, вместо Couchbase была Монго (это похожая NoSQL-база). Начали набирать разработчиков.

Тогда были Java 7, Wildfly (бывший JBoss) и SVN. По мере развития проекта поняли, что нужно делать много чего по-своему (потому что так быстрее и проще, чтобы не поддерживать ненужное нам легаси, в частности), и стали расширяться уже и на другие технологии. Оказалось, они были бы не против, но через пару лет. Мы спросили, почему они не переходят на Java 8, GIT и Tomcat. Так мы слово за слово и решили отделяться окончательно. А пока, родные, пишите на старом стеке. Бизнес разобрался, в чём вопрос, какие плюсы и минусы есть, и всецело поддержал.

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

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

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

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

Аналитик обычно играет роль владельца продукта либо на это место приходит человек из бизнеса. Фича-команда — это небольшая группа людей (обычно аналитик, тестировщик, разработчик бека и разработчик фронта, опс). Он их диктует разработке. У владельца есть беклог, приоритет, задачи. У нас нет тимлидов для оценки задачи, кодревью и принятия решения. Разработчик выбирает вариант реализации сам, обсуждая в команде, что и как будет сделано. Обычно более опытные в команде дают мнения, на которые многие готовы положиться. Все делают всё. Конечно, бывают конфликты, когда два разработчика не могут договориться про реализацию фичи. Но любой может принять решение. Но большая часть — это выбор решения по реализации. Если конфликт перешёл на личности — нужна эскалация до руководителя. Обычно получается быстро, но были случаи, когда и целый день спорили. Тогда все стоят и рисуют около доски пока не найдут устраивающий всех вариант. Ему объясняют суть проблемы, он решает. Когда спор заходит в тупик, часто зовут арбитра — человека из другой команды, мнению которого все доверяют. В этом процессе спора в теории может участвовать даже джун или практикант, но я знаю всего пару таких случаев — обычно у джунов есть наставник, которого они слушают.

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

На деле это оказалось не очень эффективно. Изначально мы не хотели делать отдельных тестировщиков: был тренд, что разработчик должен либо идти по TDD-методологии, либо сам тестировать свой код до конца. Тесты нужны тебе для того, чтобы твоё приложение работало правильно. Поначалу всё шло хорошо: написал — отвечаешь. Какие-то приложения отмирали, какие-то уходили на прод и не менялись месяцами. Но потом, чем больше становилось задач и приложений, тем было сложнее. Аналитики в командах менялись. Стало тяжело писать тесты, поддерживать их и так далее. Но разработчики не перестают писать тесты и — иногда — делать TDD. Относительно недавно договорились, что были неправы: тестировщики нужны. И для второго нужны именно тестировщики, поскольку они покрывают возможные странные случаи не только юнит-тестами. Мы для себя осознали, что тесты, которые проверяют функционал (приложение работает правильно), и тесты, которые проверяют, что приложение работает в проблемных ситуациях, — это должны делать разные люди.

Ещё есть аналитики, тестировщики и поддержка. Сейчас чисто разработчиков 60 человек — бек, фронт, фуллстеки. Но всё равно 200 планируемых людей из заголовка не набирается, поэтому мы сейчас ищем новых людей, потому что поле работы огромное. И плюс дополнительно ещё семь девопсов. То есть из разработки у нас сейчас 74 примерно из 200. Вакансии есть на Моём круге, если что.

InnerSource

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

Проект оформляется по единым правилам оформления. В рамках группы ADEO всех подразделений по странам весь код лежит в облачном Гитхабе. Когда у тебя открытый код и понятные правила оформления — любой разработчик на стеке может контрибьютить. Ограничений по стилю, технологиям и инструментам нет. Чтобы законтрибьютить тебе в код, нужно прочитать доку, клонировать репозиторий, внести правку, отправить пулл-реквест.

В настоящее время Бразилия, Россия и Франция очень активно используют эту общую базу.

При анализе мы создали карту на две оси: техническая сложность перевода в режим иннерсора по одной оси и вторая ось, насколько перевод в иннерсорс вообще полезен. Мы сейчас стараемся весь код подрядчиков (а у нас их очень много по разным направлениям) перенести в InnerSource. А вот если много команд используют этот участок — точно нужно. Если код уникальный и нужен только в одном месте — возможно, не надо его даже трогать.

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

Ещё немного нюансов

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

Не прошёл Сонар — нет релиза. Сборка делается в Jenkins, код прогоняется в Сонаре (точнее, уже SonarQube). База данных даётся как сервис инфраструктурщиками. Тестировщики пишут автотесты, владельцы кода — функциональные тесты. Полноценное нагрузочное тестирование делается в редких случаях, поскольку структуры тестовой базы и основной отличаются: на препроде у нас хаотичные данные, а не обезличенные реальные (это один из шагов в будущем), поэтому накатывать надо нежно и не всё сразу.

Скоро должны поехать в Kubernetes (а часть новых продуктов вроде маркетплейса уже изначально там), как только разберёмся с планом перехода и договоримся по всем мелочам в инфраструктуре.

Ну а вы можете следить за нашим реалити-шоу (потому что всё только строится и быстро меняется) и делать ставки, облажаемся мы или нет. Мы с коллегами продолжим рассказывать про то, как какая часть работы устроена, потому что почти везде можно углубляться бесконечно.

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

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

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

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

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