Купили невесомый саморез за 0 рублей и теперь думаете, куда прикрутить? Размышляете о теории заговора в лице пиар-службы магазина? Хорошо, если не понимаете, о чём идёт речь. Это значит, что до вас не добрался мем с весами, которым почему-то все родственники считают важным со мной поделиться.


Начало и развитие истории, откуда я взял эту картинку.

История с весами мне напомнила случай, который случился на старте карьеры в Леруа три года назад. Я пришёл в эту компанию на позицию бэкенд-разработчика и сразу попал на трёхнедельную интеграцию: предстояло побывать почти на всех ролях в магазине. Через пару недель уже поработал с местным айтишником (привет, Коля!), ночью потаскал коробки на складе и разобрался в устройстве кухонной вытяжки. Как это было, это отдельное приключение, достойное собственного поста. Парой слов: для разработчика это необычный опыт, который даёт прочувствовать боли сотрудников и покупателей на собственной шкуре.

В один прекрасный летний день к нашей команде пришла коллега из отдела контента сайта и попросила сделать инструмент для публикации информации о работе кафе и туалетов во всех магазинах страны. И все бы ничего, только мы не имеем никакого отношения к кафе и туалетам, а занимаемся “Платформой услуг”, благодаря которой наши клиенты могут нанять профессионалов в ремонте и обустройстве дома.

На мой вопрос: “Почему ты пришла к нам?” — мне был дан простой ответ: “Кафе и туалеты — это тоже услуги для клиентов!” Здесь вспоминаются слова Рене Декарта: “Если бы среди философов навсегда установилось согласие относительно значения слов, то почти все их споры были бы прекращены” (“Правила для руководства ума”).

Мы работаем продуктовой командой, и у меня встал вопрос: как описать наш продукт так, чтобы каждый понимал, что мы делаем и в чем мы можем помочь? Чтобы дать на него ответ, я решил разобраться, что означает само слово “продукт”.

Результат моих изысканий под катом…

У вас когда-нибудь было такое состояние?


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

Ниже я покажу, где были самые большие различия.

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

Оказалось, я не один такой и схожие ощущения возникают у многих моих коллег. И тогда я решил, что либо научусь писать нормально, либо пора менять профессию. Я попробовал test-driven development в попытке что-то изменить в своём подходе к программированию.

Забегая вперёд, по результату нескольких проектов, могу сказать, что TDD даёт более чистую архитектуру, но при этом замедляет разработку. И подходит не всегда и не всем.

Четыре года назад база клиентов велась отдельно в каждом магазине плюс ещё одна — на сайте.

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

Самый простой юзеркейс: сделать заказ через сайт и забрать его в реальном магазине «Леруа Мерлен» в России. Раньше заказы интернет-магазина обрабатывались в другом приложении вообще и по другой схеме. Теперь нам нужна была омниканальная витрина, чтобы любой заказ был разбит на интерфейс: касса в магазине, мобильное приложение, терминал в магазине, сайт — что угодно. Если вы поставите Linux на микроволновку — пускай будет микроволновка. Главное, чтобы какие-то интерфейсы могли стучать по API к беку и говорить, что вот тут надо оформить такой-то заказ. И получали на это внятный ответ. Вторая история была с запросами наличия и свойств товара из его карточки.

На фронте (скоро и про это напишем) у нас монстр — AEM, а за ним в беке было два больших приложения: OPUS и MoVe. Первое — это база данных свойств каждого товара (от габаритов до описания), второе — отвечает за чекаут, то есть монолит касс. Если сильно упростить.

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

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



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

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

Мы, команда разработчиков, делаем корпоративные сервисы Леруа Мерлен. И у нас есть одно преимущество, которым может похвастаться мало какой разработчик: у каждого сотрудника компании есть телефон, где всё это запускается.

То есть мы можем быть уверены, что, если завтра будет релиз приложения для инвентаризации, то все пользователи его получат. И смогут мгновенно использовать.

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



Как видите, тут корпоративные приложения соседствуют с соцсетями, Телеграмом и прочим «бытовым» набором. Мы поощряем использование мессенджеров и соцсетей с корпоративных устройств. Принципиально не отслеживаем пользователей и не обращаемся к их данным (французская политика приватности в MDM примерно на уровне GDPR).

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

У нас в Леруа есть много товаров, которые хотелось бы поставить на полки. Например, побольше видов обоев. Или профессиональное оборудование. У нас есть материалы для отделки спален, но нет кроватей и постельного белья. И так далее. 16 миллионов человек ежемесячно посещают сайт при населении России 146,8 миллиона человек. Поверьте, нашим покупателям хочется много чего, кроме 40 тысяч товаров основного ассортимента.

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

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

В случае успеха это такое резкое изменение бизнес-модели, что можно гордиться ещё года три. А внедрять всё пару месяцев. Как нам поначалу показалось.

Нужно было успеть адаптировать все ИТ-системы до конца строительства магазина.

В 2016 году было решено открыть магазин в Казахстане (в Алматы). В логике группы компаний Adeo (это все магазины Leroy Merlin по всему миру) на каждую новую страну нужно создавать отдельный бизнес-юнит со своей инфраструктурой и всем-всем-всем. Например, Украина — это отдельный юнит из пяти магазинов со всеми собственными подразделениями, службами и ИТ-процессами.

На Казахстан мы решили (впервые в истории развития компании) сделать форк российской инфраструктуры, фактически расширяя наши системы на новый регион. Почему? Потому что закупки, цепи поставок, юридические и финансовые службы централизованы. Рынки близки. Законодательство близкое, хотя и есть свои особенности (каждый департамент выявлял для себя отличия с помощью коллег из юротдела). Это евразийский Таможенный союз. У нас было 90 магазинов в России, и можно было закупать на условиях, которых в Казахстане поставщики просто не дадут, да и местного производства не так много. У нас много отлаженных процессов, работающее ПО и так далее.

Осталось только чуть-чуть докрутить пару ИТ-систем. Простая работа года на полтора, потому что переписать пришлось не всё, но очень-очень многое. Началось с того, что, оказывается, надо подписать дополнительные соглашения с 800 поставщиками, чтобы их товары правильно маркировались и сертифицировались при необходимости. Чтобы в Казахстане их можно было правильно учесть, соответственно и правильно напечатать ценник, на котором по закону наименование товара должно быть на казахском и русском языках.

На этом сюрпризы только начинались.