Привет, Хабр! Меня зовут Евгений Сальников, я тимлид одной из команд доставки в компании Lamoda. В нашей команде используются сразу пять языков программирования: PHP, Go, Vue, Typescript, Java и Kotlin. Когда я впервые услышал об этом на собеседовании, подумал, что так работать невозможно все слишком разное. Но спустя год мое мнение кардинально изменилось, и я нашел много преимуществ в таком подходе.
В этой статье я расскажу:
- о нашем направлении и системах, обслуживающих доставку;
- как мы живем с таким разнообразием технологий;
- как планируем работу над разноплановыми задачами;
- как растим экспертизу в fullstack-команде и расширяем направление.
Почему fullstack?
Мы часто слышим про fullstack это устоявшееся понятие, даже избитое. Оно подразумевает, что один человек может пилить и бекенд, и фронтенд все в одном флаконе. Сейчас в нашем направлении уже четыре команды из 27 человек, пять языков и четыре системы.
- DataMatrix это система для маркировки товаров. В нашей стране существует закон 487-ФЗ, по которому мы обязаны помечать ряд товаров QR-кодом. Маркировка содержит информацию о том, кто произвел этот товар, кто ввез в страну, когда он поступил в продажу. Это помогает понять, насколько легальная вещь лежит перед нами. Подробнее о DataMatrix рассказывали в отдельной статье.
- Система Express стоит в каждом пункте выдачи заказов и во всех транзитных складах. Она целиком написана с нуля внутри Lamoda, поэтому там учтены все наши процессы и потребности. На текущий момент вся система доставки построена на Express.
- Система XDC взаимодействует с внешними службами доставки с Почтой России, DPD и остальными.
- Также в зоне ответственности нашего направления мобильное приложение для торговых представителей, у которых есть планшет или телефон с ПО нашей разработки.
Мы стараемся стандартизировать все системы. Например, если что-то пишем на РНР, то делаем это одинаково: используем одинаковые фреймворки и библиотеки. Но есть задачи, которые нужно решать иными способами. И в таком случае я не разделяю подход, что все можно написать на одном языке программирования. Как правило, это не всегда оправдано и может приводить к неожиданностям. Для разных задач уже существуют готовые наработки или другие технологии. На мой взгляд, это нормально.
Мой любимый пример Apache Camel. Это интеграционный фреймворк на Java, который, грубо говоря, перекладывает данные из одного места в другое. У нас в компании эта технология обеспечивает взаимодействие с внешними курьерскими службами: мы получаем данные о заказе из API, преобразовываем их и отправляем в курьерскую службу. Написать эту задачу на РНР возможно, но будет неоправданно, потому что Apache Camel и так уже создан для этих целей. Такой подход позволяет легче адаптировать новые службы и новые API, тратить меньше времени на преобразование запроса из Json в XML. В Lamoda это адаптированная технология: если одна команда научилась ее готовить, мы делимся знаниями с коллегами. Сейчас Apache Camel используется уже в четырех командах.
Распределение ролей, покер-планирование и рост экспертизы
Раньше мне казалось, что существует жесткое разделение по системам. Например, пять человек занимаются одной системой, еще пять занимаются другой и просто взаимодействуют друг с другом. У нас такого нет. Каждый инженер команды может дорабатывать любую систему.
Например, у нас есть задача сделать удобную форму возврата. Для контроля технической стороны этого проекта мы назначаем техлида, которым может стать любой инженер из команды. Уже заранее он понимает, что для поставленной цели придется затронуть две системы: Express и XDC.
На схеме видно, что у Express и XDC также есть техлиды. У Express их даже два это очень большая система. Таким образом, техлид проекта сообщает техлидам систем о необходимых доработках, составляет и декомпозирует задачи, следит за тем, чтобы работа шла консистентно.
В то же время на всем направлении работает системный архитектор. Это серьезный специалист, который помогает всей разработке двигаться в едином направлении.
Планировать и оценивать задачи в нескольких системах сразу достаточно сложно, потому что может получиться неточный результат. В нашем подходе мы живем по двухнедельным спринтам. Встречаемся на общих встречах на грумингах и планнингах и используем покер-планирование для командной оценки задач по системе. Каждый человек оценивает все задачи, исходя из собственного опыта и экспертизы. Таким образом, мы получаем средние оценки выполнения всех задач, которые отображают реальные сроки.
Как я уже упоминал ранее, любой инженер может дорабатывать каждую из наших систем. Допустим, человек начинал работать только с одной из них чаще всего с Express, так как все наши системы и процессы так или иначе связаны с доставкой. Новичку мало понимать ее технически, требуется знать предметную область и разбираться в процессах, которые там происходят. Таким образом, человеку, который изучил одну систему, будет намного проще работать над задачками по доработке другой. Порог вхождения во что-то новое становится гораздо ниже.
Приведу несколько примеров нашего подхода к работе:
- Раньше я часто сталкивался с тем, что есть отдельная команда для бэкенда и API мобильного приложения, а другая команда дорабатывает само приложение. Это требует формализации всех процессов и задач. У нас же один и тот же человек в одном спринте дорабатывает бэкенд и API мобильного приложения, да и само мобильное приложение. И это не разные задачи, а один проект по общим изменениям. На мой взгляд, это позволяет двигаться быстрее.
- Следующий пример о том, как мы близки к инфраструктуре. В нашем направлении используется K8s и Atlassian. Все скрипты для разворачивания новых серверов или деплоя приложения также создаются внутри команды. Любой из наших инженеров может поправить скрипт деплоя или что-то написать на Ansible, чтобы развернуть новый сервер. Благодаря этому мы быстрее делаем доработки.
- В нашей команде есть сервисы, написанные на Go, но исключительно утилиты. Часто бывает так, что нам нужно запросить миллион Data matrix у внешнего API. В этом случае писать большие истории на РНР невыгодно, потому что для этих целей создан Go. Это бы усложнило ситуацию, если инженер совсем не знаком со сторонними API и с нашими процессами. Но наши ребята могут написать нужную утилиту на подходящем языке. Go адаптирован к нашей компании. У нас есть экспертиза в этом, мы можем пойти к соседним командам и уточнить у них все вопросы.
Год назад я не верил, что такая работа возможна. Но все мои страхи о том, что ее невозможно планировать, не подтвердились. Практика показывает, что fullstack-работой можно управлять и такой подход значительно развивает экспертизу в команде.
Мои итоги спустя год: как расширять fullstack-команду
Fullstack-программист стоит дороже, чем остальные. В HR-отделе на вас посмотрят с недоумением, когда вы попросите найти специалиста, который умеет Go, Java, Kotlin и отлично знает РНР.
Есть три способа увеличить команду:
1. Брать со стороны. Чтобы попасть в нашу команду, не нужно знать все пять языков. На старте большинство из нас были с ними не знакомы. Достаточно знать РНР и SQL и не бояться работы с остальными технологиями и языками. Мы на каждом интервью сразу же говорим о том, что у нас используется несколько языков.
Также у нас выстроен процесс онбординга он длится 3 месяца. Каждый новичок получает план из набора технических задач, которые в совокупности охватывают все наши системы и технологии. Например, сначала РНР-разработчик начинает знакомиться с системой Express, а потом может выбрать другие задачи, исходя из своих интересов: кому-то больше интересен Kotlin, кто-то уже имеет экспертизу на Go. Также происходит постепенное погружение и в процессы команды: дежурства, знакомство с системой мониторинга, выполнение саппорт-задач.
2. Растить внутри. Процесс, запущенный на онбординге, не заканчивается ровно через 3 месяца. Человек по-прежнему продолжает погружаться в наши процессы, а его технологическая экспертиза растет. Со временем он может занять роль техлида. Для этого инженер знакомится сначала с системой, потом с бизнес-требованиями к ней, а со временем понимает, что бизнес-требования слишком велики для одной задачи. В таком случае он может стать техлидом этого проекта или системы. Погружение в такую работу происходит только через практику.
Новичкам же мы даем исключительно технические задачи, которые не сильно влияют на бизнес-составляющие. Поэтому там нет горящих сроков, и никто не будет торопить человека, который только недавно начал разбираться в новой области знаний. Мы понимаем, что если сотрудник впервые видит систему и эту технологию, погружение займёт какое-то время. С ростом вовлеченности инженера растет бизнес-составляющая этих задач и экспертиза сотрудника.
В таком подходе важно понимать, что разработчик это инженер. Для меня инженер это человек, который продолжает учиться, искать что-то новое и понимает, какие технологии лучше подходят для решения конкретной задачи. Ему важно постоянно развиваться, не зацикливаясь на чем-то одном. Я верю, что смена проекта помогает разнообразить жизнь инженера. Очень здорово, когда в команде есть несколько проектов, между которыми можно переключиться и попробовать разное. Это не даст заскучать.
3. Смена технологий. Это тоже отличный путь развития. Сначала я познакомился с РНР, и казалось, что на нем можно сделать абсолютно все. Но сейчас будет странно писать на РНР постоянно живущие воркеры. Для этого можно использовать другие языки. Или, например, когда я познакомился с Go, это казалось крутым, но чего-то не хватало, зная количество готовых библиотек для Java. Новые инструменты помогают лучше понять те, которыми уже владеешь.
За неполный год в мою команду добавилось еще 10 инженеров. Сейчас это уже целое направление. Но не все готовы работать в таком подходе: кому-то не зашёл фронтенд, кому-то не заходит разнообразие технологий. Это не значит, что ушедшие люди плохие инженеры. Мы работаем в огромной компании, поэтому возможен переход в другие команды внутри Lamoda. Бывают и обратные случаи, когда люди из других команд переходят в наше направление, и это тоже круто.
Новые языки и комплектность команды
Мы уже сталкивались с появлением новых языков: кто-то сразу же на них кидается, кто-то ждет, когда появятся стабильные версии. Мы не отрицаем тот факт, что какие-то задачи можно реализовать легче или быстрее на других технологиях. Да, не нужно зацикливаться на чем-то одном, но лучше здраво подходить к каждому выбору. Если появятся новые языки или новые технологии, которые позволят нам двигаться быстрее, конечно, мы их рассмотрим.
Также иногда встает вопрос о комплектности команды: сколько человек должны знать каждый язык. Такого минимума у нас нет. Приведу пример: человек, который знает один из языков, взял бы переходящую роль техлида и проект, где предполагается использовать новую технологию. У нас есть архитектурные комитеты, где мы доказываем, что такая технология оправдана. Если она уже адаптирована в компании, то мы можем брать ее в работу без архитектурного комитета. Техлид нарезает задачи часть из них будет исключительно техническими. В процессе реализации остальные участники команды познакомятся ближе с нужной технологией. Таким образом, мы взращиваем экспертизу. И постепенно все больше и больше инженеров знакомится с новой технологией. В конечном счете этот проект в команде будет реализовывать точно не один человек.
Подведу итог: расширять fullstack-команду возможно. Практика показывает, что можно брать инженеров со стороны и можно растить их внутри компании. Если у вас есть свой опыт формирования fullstack-команды, поделитесь им в комментариях.
