Бэкенд vs фронтенд: батл разработчиков X5 Tech

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

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

Наши бойцы давно готовились к этому матчу. Тренировочный процесс построен максимально эффективно: в каждой команде по 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.Транспорт» мои ребята помогают обрабатывать десятки гигабайт информации в онлайне. Поверьте, это лютая тренировка!

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

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

• «X5.Транспорт»;
• «Система оперативного мониторинга»;
• «Операционная аналитика транспорта»;
• «Объединённый центр обслуживания»;
• «Обратная связь»;
• «Реаллокатор полочного пространства»;
• «Управление промоактивностями»;
• Customer Value Management;
• «Система планирования ассортимента»;
• «Ценообразование»;
• Dialog.X5 (цифровая платформа для поставщиков).

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

• «Система оперативного мониторинга» постоянно собирает данные с датчиков грузового транспорта и практически в режиме реального времени выдаёт диспетчерам на картах местоположение машин и информацию об их состоянии. Это десятки гигабайт информации на входе, которые нужно корректно обработать, сложить в аналитические хранилища и ретранслировать в соседние системы для дальнейшей обработки.
• «X5.Транспорт» отслеживает грузоперевозки и управляет ими в режиме реального времени. Она предоставляет API для интеграции с партнёрами, а пользователям — веб- и мобильный клиент.
• «Обратная связь» — наш лучший сервис по работе с обращениями покупателей торговой сети «Пятёрочка». Включает в себя три информационные системы с единым веб-интерфейсом: CRM (единое окно оператора), TTS (тикетная система обращений клиента) и омниканальная платформа коммуникаций.
• Dialog. X5 — цифровая платформа для поставщиков. Целая экосистема сервисов для автоматизации бизнес-процессов и аналитики данных ретейла.

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

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

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

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

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

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

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

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

• товар;
• стек;
• партия;
• айтем.

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

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

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

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

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

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

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

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

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

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

1. Общее впечатление от докладчика. Держится уверенно; спортивного телосложения — наверняка занимается в спортзале. Проявляет лидерские качества и может убедительно доносить свои мысли. Мне даже показалось, что это менеджер-шпион в стане разработчиков.
2. Техническая часть. Хорошо получилось обратить внимание аудитории на важность проектирования перед началом разработки. Докладчик приводит яркие примеры из жизни компании, которые демонстрируют процесс внедрения в работу правильных техник. Можно было ещё добавить ссылки на полезную литературу. Например, с темой доклада резонируют «Пользовательские истории. Искусство гибкой разработки ПО» Джеффа Паттона.
3. Художественная часть. Докладчик разбавлял сухие технические термины наглядными примерами из практики, а также использовал отсылки к историческим личностям. Складывается впечатление, что все описанные ситуации он пережил лично и впитал полученный опыт на генетическом уровне. Словарный запас достаточный для тимлида и ведущего разработчика, при этом нет воды.
4. Сильная сторона доклада. Лучше всего получилась художественная часть: информация преподнесена красиво и доступно.

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

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

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

1. Ценный опыт в сфере hard skills. Раньше, столкнувшись с проблемой — связанной с написанием кода, тестированием, управлением версиями или любой другой стороной разработки, — вы были вынуждены самостоятельно перебирать большое количество вариантов решений, многие из которых не приводили к нужным результатам. Теперь больше нет необходимости проводить бессонные ночи на форумах и учиться на своих ошибках: можно просто обратиться к коллеге, который уже сталкивался с подобной ситуацией. Он не только укажет правильный путь, но и объяснит, к чему могут привести неверные решения.
2. Возможность поделиться своим опытом и экспертизой. Разумеется, вы и сами станете источником опыта для своих коллег. Некоторые могут возразить, что если открыто делиться с другими всем, что вы узнали и поняли, то можно перестать быть работником с уникальными знаниями, так как любой из коллег сможет вас легко заменить. Но обсуждение проблемы — это улица с двусторонним движением: собеседники тоже выскажут своё мнение и помогут посмотреть на привычный вопрос под новым углом; вы получите новую пищу для размышлений и станете лучше понимать предмет обсуждения.

   — Надо видеть лица слушателей! У них в голове происходит революция: как это, упускать такой ценный инструмент манипуляции работодателем? Просто так взять и раскрыть все тайные закорючки в коде?

3. Рост soft skills. Работники крупной компании многочисленны и делятся на команды. Вам придётся часто взаимодействовать как со своими ближайшими коллегами, так и с людьми из других команд; как с теми, чьи технические навыки схожи с вашими, так и со старшими сотрудниками, которые станут для вас отличными наставниками. Причём общение будет разнообразным: от внутрикорпоративных митапов до неформальных бесед в столовой или курилке. Всё это поможет научиться лучше понимать коллег и более эффективно доносить до них свою точку зрения, а со временем находить решения, которые устраивают всех. Это прекрасная возможность вырасти из разработчика до тимлида или менеджера проекта.

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

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

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

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

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

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

1. Общее впечатление от докладчика. Кодер старой школы, инженер советской закалки. Каждое слово чеканит, как ударник производства.
2. Техническая часть. Очень много полезной информации, о которой в западных книжках обычно не пишут. Докладчик касается вопросов самосовершенствования, обмена опытом и коммуникации с коллегами; рассказывает о системах, спрятанных «под капотом» крупной корпорации (микросервисы).
3. Художественная часть. Докладчик производит впечатление ветерана, рассказывающего молодым бойцам о том, что их ждёт на фронте. Каждому слову хочется верить безоговорочно; сразу видно, что примеры он приводит из собственного опыта и из опыта работы своих коллег.
4. Сильная сторона доклада. И техническая, и художественная составляющие представлены на отлично. Всей команде разработчиков рекомендуется пересматривать это выступление хотя бы раз в месяц для поднятия боевого духа. Доклад действительно способен мотивировать молодых специалистов пойти работать в большую компанию и развивать свои профессиональные навыки.

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

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

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

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

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

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

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

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

Итак, раунд!

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

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

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

• Можно работать в декларативном стиле и в каждом запросе указывать, какие поля и операции необходимы. Когда нужно получить из 100 колонок товаров только несколько полей, это очень помогает.
• Есть возможность передавать очень сложные данные, которые включают в себя избыточную информацию по типам.
• В одном запросе можно обратиться сразу к множеству ресурсов, собрав сложную структуру из нескольких сущностей. Если бы использовался традиционный REST API, то пришлось бы выполнять несколько последовательных запросов, каждый раз извлекая часть полезной информации для следующего запроса в цепочке.
• В Apollo Server есть система подписок и встроенный кеш.

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

• Несовместимость со старыми бэкенд-приложениями. Ресурсы разработчиков ограничены, и, чтобы заставить программистов переделать старую архитектуру, приходится тратить много времени на согласования. Также всё ещё остаются опасения, что GraphQL со временем потеряет актуальность и все труды окажутся напрасными.
• Ответы в формате GraphQL имеют большой размер. Если стандартный JSON-ответ с похожими данными весит 100 КБ, то его аналог на GraphQL может достигать нескольких мегабайт. Поэтому в некоторых случаях приходится использовать старый добрый JSON.
• При увеличении количества клиентов сервер Node. js может быть перегружен. Это можно исправить, если запускать его в нескольких потоках. Правда, тогда возникнет проблема с синхронизацией, но и она решаема.

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

1. Общее впечатление от докладчика. Добряк и шутник; скорее всего, душа компании. Вероятно, это и есть характер типичного фронтендера.
2. Техническая часть. Рассказ про GraphQL содержит много полезной информации: видно, что программист хорошо разбирается в своей тематике и может рассказать о ней.
3. Художественная часть. Хорошее чувство юмора и уместно вставленные шутки помогли докладчику донести до аудитории суть непростой работы фронтендеров.
4. Сильная сторона доклада. Если когда-нибудь вы задумаетесь о том, не слишком ли сложен GraphQL для вашей задачи, пересмотрите это выступление, улыбнитесь и возвращайтесь к работе. Теперь вы знаете, где эта технология пригодится, а где только помешает.

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

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

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

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

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

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

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

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

1. Общее впечатление от докладчика. Очень приятная и симпатичная девушка с поразительным запасом слов. Чтобы её послушать, я ни одного митапа не пропустил бы.
2. Техническая часть. Из доклада можно узнать много нового о метриках Google PageSpeed и о том, к каким трюкам можно прибегнуть, чтобы перехитрить эту систему оценок. Также раскрыт интересный парадокс, когда излишняя оптимизация улучшает Google-метрики, но в тоже время добавляет в загрузку новые скрипты, которые по факту увеличивают нагрузку на браузер пользователя.
3. Художественная часть. Все перипетии — от постановки проблемы до решения и обнаружения парадокса — поданы с лёгким юмором и обаянием.
   
   
4. Сильная сторона доклада. Одинаково хорошо получились и техническая, и художественная часть. Пример того, как изящно можно вплести в увлекательное повествование множество сложных терминов.

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

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

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