Секреты fullstack-команды: когда любая утилита по плечу

Когда один специалист способен пилить и бекенд, и фронтенд — это называется fullstack. Именно так, в четырех системах и на пяти языках программирования в отделе автоматизации бизнес-процессов Lamoda работают 27 человек. Это четыре команды разработчиков. Они пишут сразу на PHP, Go, Typescript, Java и Kotlin.

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

Любую работу в Lamoda мы стараемся стандартизировать, создавать все решения на одном языке по определенным правилам. Впрочем, бывают задачи, которые нужно решать нестандартно для нашего подхода. Благодаря разумному выбору программных продуктов, специально созданных под определенные задачи, мы значительно экономим ресурсы и время. Яркий пример — Apache Camel. Это интеграционный фреймворк на Java, который используется в сервисе для взаимодействия с внешними курьерскими службами. Фреймворк позволяет быстрее адаптировать новые службы и новые API, тратить меньше времени на преобразование запроса из Json в XML. Написать все это на PHP можно, но будет нерационально, так как эта технология уже предназначена для решения этих задач.

Таким образом, Apache Camel — это адаптированная технология в Lamoda, которая используется уже в четырех наших командах. То есть, если одни научились ее использовать, то они делятся этими знаниями с другими. Поэтому у нас нет четкого разделения по системам, так как каждый инженер команды может дорабатывать любую из них.

Наши системы

  • DataMatrix. Мы обязаны маркировать ряд товаров QR-кодом по Федеральному закону №487. Отсканировав код, можно получить информацию о производителе, импортере, старте продаж товара. Это помогает определить подлинность вещи.
  • Express. Система работы в пунктах выдачи заказов и на транзитных складах. Это самописная система, которая обрабатывает всю логистику Lamoda.
  • XDC. Система сотрудничества с логистическими партнерами: Почта России, DPD и другими.
  • Мобильное приложение для торговых представителей. Это софт нашей разработки, который позволяет отмечать те вещи, которые были взяты и оплачены пользователем.

Как мы справляемся с этим всем

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

В Lamoda один инженер в рамках одного спринта может дорабатывать и бэкенд, и API мобильного приложения, и само приложение. Любой способен поправить скрипт деплоя и написать что-то на Ansible, чтобы развернуть новый сервер. Бывает, что нам нужно запросить миллион Data matrix у внешнего API. Писать большую программу на PHP для этого невыгодно. Для таких задач есть язык Go. Мы всегда можем обратиться с вопросами к соседним командам, у которых есть экспертиза в этом языке.

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

Планирование и рост экспертизы

Как я уже упоминал выше, в нашей команде среди инженеров нет распределения по специализациям: каждый может доработать любую систему. Например, для создания новой эффективной формы возврата нужно затронуть системы Express и XDC.

Для контроля технической стороны этого проекта мы назначаем техлида, которым может стать любой человек из команды. У Express и XDC по отдельности также есть техлиды. У Express их аж два, потому что это очень крупная система. Задача техлида проекта заключается в том, чтобы поддерживать плотную коммуникацию с техлидом системы и информировать его о необходимых доработках, составлять и декомпозировать задачи, следить за тем, чтобы работа шла консистентно.

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

Для наиболее эффективного планирования и получения точного результата, мы двигаемся двухнедельными спринтами и используем Покер-планирование (англ. Planning Poker или Scrum poker). Это техника оценки сложности или относительного объема предстоящей работы. Такая система основана на достижении договоренности: специалисты прогнозируют, сколько времени займет та или иная задача на основе своего опыта. Каждый участник команды дает предстоящей задаче оценку, из суммы которых складываются наиболее реалистичные сроки.

Как формировать fullstack-команду

Fullstack-программист — очень дорогой специалист. На рынке их немного. Вот что я рекомендую сделать, чтобы снять дефицит таких кадров в своей команде.

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

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

  • Менять технологии. В 2021 году странно считать, что абсолютно все можно написать на PHP. Есть другие языки. Более того, знание множества технологий помогает инженерам лучше понимать недостатки каждой из них.

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

Все мои страхи о том, что такую работу невозможно спланировать не подтвердились. Наоборот, такой подход показал мне, что fullstack-работой еще как можно управлять и тем самым развивать экспертизу. Если у вас есть опыт формирования fullstack-команды, поделитесь им в комментариях.

0
40 комментариев
Написать комментарий...
Сергей Сергеев

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

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

Ответить
Развернуть ветку
Илон Маск

👍

Ответить
Развернуть ветку
Lamoda
Автор

☺️

Ответить
Развернуть ветку
Victor Pomortseff

Вот читаю подобные вещи и думаю - а что такое backend в понимании автора? Просто то, где нет интерфейса? Т.е. есть UI - фронт. Нет UI - бэк...

Вот, к примеру, как это выглядит у нас:

4 уровня. Из них фронт - самый верхний. А бэк - самый нижний. Он вообще отделен и недоступен снаружи по требованиям ИБ. Все общение с ним через сообщения в очередях и EIB шину.
На бэке сплошь системные API, С++ (и еще пара специфических языков) и прямая работа с БД.
И вот хотелось бы посмотреть на человека, который одновременно хорошо умеет Swift/Kotlin и при этом знает все тонкости системных API платформы IBM i, C/C++, RPG, MQ API, DB2 и вот это все вот...
То что человек может уметь фронт и еще middle слои - могу поверить, но чтобы еще и бэк в том виде, в каком он у нас есть... Таких не встречал.

Ответить
Развернуть ветку
Lamoda
Автор

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

Ответить
Развернуть ветку
Victor Pomortseff

А у нас банк. Core - фактически автоматизированная банковская система. Которая внутри себя очень много чего постоянно делает. И там совсем другая платформа, на которой все это работает (IBM i на серверах Power9). И совсем другой технологический стек. И жесткие требования по производительности, ресурсам и т.п. (просто потому что там тысячи параллельных процессов постоянно работают).

И основные инструменты там - SQL, С/С++ и специфические для этой платформы языки RPG и CL

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

Ответить
Развернуть ветку
Game Topia

php = 🤢

Ответить
Развернуть ветку
Илон Маск

А какой надо?

Ответить
Развернуть ветку
Павел Морозов

Python

Ответить
Развернуть ветку
Game Topia

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

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

Ответить
Развернуть ветку
Alexey Laptev

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

Ответить
Развернуть ветку
Game Topia

Совсем недавно безумцы тоже самое и о руби говорили. Да что там, если бы лет десять назад сказать, что руби бяка, то забанили бы!

Ответить
Развернуть ветку
Alexey Laptev

Вы отстали лет на 15 по php.

Ruby - вымирает
Питон годится только для датсайнс
Go - слишком сложный и низкоуровневый для большим проектов, но микросервисы - норм.
Nodejs -  тоже самое что и Go

Php в связке с фреймворком типа yii2/laravel/symfony быстр как в работе так и в разработке, программистов завались.

Идеальная связка сейчас php + go.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Alexey Laptev

нет exception и нормальной обработки ошибок, нет orm, нет нормального фреймворка уровня yii2 где уже решены все типовые задачи.

В итоге разработка на Go по трудоемкости x10 от php, а единственное премущество Go -  высокая скорость, которая актуальна на каком нибуть api с очень высоким RPS где php реально не вывозит, но это большая редкость.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Alexey Laptev

Хорошо , назовём это - «много писанины».

Если проект не требует супер перформанса, то нет смысла писать что-то на Go - это приведёт лишь к колоссальной потере времени и денег.

Но в целом язык для своих узких задач хорош, если не пытаться писать на нем все, потому-то стало модно.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Alexey Laptev

Я видимо действительно отстал от трендов, раньше язык подбирался под задачу , а не писалось все на одном языке :)

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Rudolf Cunningham
нет orm

Так это же хорошо. Это такая фундаментально сломанная фигня, что непонятно кто в здравом уме этим пользуется в проде в 2021 в принципе.

Ответить
Развернуть ветку
Alexey Laptev

Писать самодельные запросы лучше? Когда у каждого кодера свой уникальный подход.

Ответить
Развернуть ветку
Rudolf Cunningham

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

Ответить
Развернуть ветку
Alexey Laptev

Ну так для гайдлайна и сделали orm и аналоги вроде :)

Ответить
Развернуть ветку
Rudolf Cunningham

Нет, их сделали пытаясь натянуть работу с БД на объектную модель, но получилось ожидаемо хреново.

Ответить
Развернуть ветку
Alexey Laptev

Видимо я не тем orm пользовался. Вообще никаких проблем кроме редких случаев со сложными запросами.

Ответить
Развернуть ветку
Game Topia

И очень странно звучит разделение больших проектов и микросервисов. Не находите?

Ответить
Развернуть ветку
Alexey Laptev

не нахожу

Ответить
Развернуть ветку
Game Topia

А что вы тогда под большим проектом подразумеваете? 

Ответить
Развернуть ветку
Alexey Laptev

lamoda например

Ответить
Развернуть ветку
Game Topia

Дааа....

Ответить
Развернуть ветку
Alexey Laptev

А на чем сейчас пишут православные программисты?

Ответить
Развернуть ветку
Я не скажу свое имя машине

На церковнославянском

Ответить
Развернуть ветку
Game Topia

Я с вами полностью согласен! Вы почти повторяет мои недавним комментарии. Но я не согласен, что php крут.
Вот скажите, какой фраймворк вы используете на php и какой бы использовали на nodejs, и чью идеологию они по вашему повторяют?

Ответить
Развернуть ветку
Alexey Laptev

на php - yii2, nodejs - не интересен, пустая трата времени.

Ответить
Развернуть ветку
Илон Маск

Вообще можно и без framework-ов юзать. И например PHP по скорости быстрее python. Просто питонисты на С верхом сидят, и говорят что он быстрый

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Victor Pomortseff

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

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
kitty_bot

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

Ответить
Развернуть ветку
37 комментариев
Раскрывать всегда