WB Tech
13.8K subscribers
585 photos
18 videos
223 links
Разработчики Wildberries делятся опытом: полезные статьи и анонсы мероприятий

Ютуб: https://www.youtube.com/@wb_tech

Регистрация в Роскомнадзоре:
№ 4963508866
Download Telegram
⭐️ Чем важнее задача, тем сильнее хочется заняться чем угодно, кроме нее. Крупный проект превращается в идеальный повод разобрать закладки в браузере или проверить почту в пятый раз.

⭐️ Звучит знакомо? Это не лень и не отсутствие мотивации. У мозга своя логика, которая пытается оградить вас от дискомфорта. Разбираем, как это работает и что с этим делать.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
28👍15🔥9
⭐️⭐️ Как мы построили систему вещания для десятков тысяч цифровых экранов

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

В статье:
⏹️Архитектура децентрализованной системы вещания и микросервисный подход;
⏹️Как устроено планирование эфира и почему эта задача оказалась NP-полной;
⏹️Realtime-механики: RTB, триггеры и HTML;
⏹️Как система переживает обрывы связи, контролирует устройства и формирует отчетность.

➡️ Читать на Хабре
Please open Telegram to view this post
VIEW IN TELEGRAM
👍117🔥7🥰1
⭐️⭐️ Иллюзия сложности: как мы сами замедляем свои команды

Команда работает больше, процессов добавили, людей наняли. А результат тот же. Или хуже. Почему улучшения не работают? Антон Марунько, TechLead Финтеха в клиентском приложении Wildberries, рассказал, как перестать улучшать всё подряд и начать делать команду быстрее:

➡️ Почему масштабирование команды не даёт результата (и что делать вместо этого);
➡️ Когда стоит делегировать задачи, а когда нет;
➡️ Как найти одно узкое место, которое тормозит всю систему.
В статье — разбор реальных кейсов от IT-команд до распределенных продуктовых групп, с примерами правильных и ошибочных решений.

➡️ Читать на Хабре
Please open Telegram to view this post
VIEW IN TELEGRAM
116👍16🔥11👏1
💡Кто ты на код-ревью?

— Апрувни мой PR, пожалуйста.
— Сейчас... оставляет 25 комментариев

⭐️ Семь типов ревьюеров. Узнаешь кого-то из команды?
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
😁5710👍7
channelName := "WBTECH"
channelName =
strings.ReplaceAll(channelName, "WBTECH", "WB Tech")
fmt.Printf("Канал %s готов к работе. Дальше — интереснее!\n", channelName)
🔥50😁227👍1
Channel name was changed to «WB Tech»
🟣 Привет! А давайте просто поговорим? Задали насущные вопросы про технологии и команду Александру Сырцову, Head of Frontend клиентского сайта Wildberries.

Мини-интервью — ниже.

Какие самые большие мифы вокруг фронтенд-разработки тебе встречались?

Миф 1. Фронтенд обязательно должен быть «глупым». Получили данные — отрисовали, изменили — отправили обратно на сервер.

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

На таких высоконагруженных проектах, как наш, фронтенд — это сложная инженерия: управление состоянием тысяч динамических элементов, оптимизация времени загрузки на медленных соединениях, построение архитектуры, которая масштабируется вместе с ростом бизнеса, а также прямое влияние на конверсию и Core Web Vitals.

Миф 2. Мобильная и десктопная версии могут сильно отличаться.

Для нас критически важна консистентность. Пользователь может начать покупку в приложении или мобильном браузере, а завершить её на десктопе. Поэтому единая логика, дизайн-система и API — это не nice to have, а обязательное требование.

Миф 3. Производительность фронтенда — это забота только фронтенд-разработчиков.

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

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


Какое самое необычное решение по оптимизации фронтенда тебе когда-либо приходилось применять?

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

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


Какие изменения произошли в экосистеме фронтенд-технологий за последнее десятилетие и как они повлияли на твою работу?

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

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

Я отношусь к новым технологиям как к инструментам. Здорово, когда у тебя есть удобный «мультитул» — молоток с фонариком и отвёрткой в одном устройстве. Но настоящий инженер должен уметь работать с любым инструментом и выбирать тот, который лучше всего подходит под конкретную задачу.
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥1912👍11