This media is not supported in your browser
VIEW IN TELEGRAM
🥩 Рубрика Well Done: бесконечный список видео
Новая рубрика, где буду делиться рецептамикулинарии рабочих задач. Какие сложности были и как их решал. Что из паттернов юзал и как борол проблемы. Сегодня в меню — карусель из сторис.
Особой сложности здесь не было, но есть интересный кейс с небольшой оптимизацией. Как это всегда бывает — изначальные требования могут много раз поменяться. Особенно по кол-ву и качеству отображаемого контента.
Тестишь ты на одном, а релизят на другом. В случае видосов это может сильно ухудшить UX.
В карусели два контента:
- thumbnail в ввиде первого кадра видоса. Для загрузки видосов
- видео-превью 3 секудны.
У всего есть предзагрузка. Все, что во viewport'е — загружается сразу + предзагрузка соседних ячеек.
Какие оптимизации тут были сделаны:
- Visibility tracking & Lazy loading: видео загружаются только когда элемент становится видимым.
- Для соседних видосов вьюпорта также запускается префетчинг. Начинаю предзагрузку в фоне до их фактического отображения, уменьшая задержку при воспроизведении
- Видосы кэшируются. если видео уходит за границы видимости, то оно должно остановиться. А в некоторых случаях и очиститься.
- Есть VideoPlayerPool (Object Pool и Coordinator cleanup). Я работаю только с плеерами, которые видно на экране. Это же нужно чтобы избежать лишних пересозданий. Экономит память.
- есть микроулучшение для low network connection
Результат подается в готовом ввиде.
В общей сумме это увеличивает перфоманс и плавность скролла на 70-85%. А также не проседает при большом кол-во видосов.
Какие рецепты предложили бы вы?
Новая рубрика, где буду делиться рецептами
Особой сложности здесь не было, но есть интересный кейс с небольшой оптимизацией. Как это всегда бывает — изначальные требования могут много раз поменяться. Особенно по кол-ву и качеству отображаемого контента.
Тестишь ты на одном, а релизят на другом. В случае видосов это может сильно ухудшить UX.
В карусели два контента:
- thumbnail в ввиде первого кадра видоса. Для загрузки видосов
- видео-превью 3 секудны.
У всего есть предзагрузка. Все, что во viewport'е — загружается сразу + предзагрузка соседних ячеек.
Какие оптимизации тут были сделаны:
- Visibility tracking & Lazy loading: видео загружаются только когда элемент становится видимым.
- Для соседних видосов вьюпорта также запускается префетчинг. Начинаю предзагрузку в фоне до их фактического отображения, уменьшая задержку при воспроизведении
- Видосы кэшируются. если видео уходит за границы видимости, то оно должно остановиться. А в некоторых случаях и очиститься.
- Есть VideoPlayerPool (Object Pool и Coordinator cleanup). Я работаю только с плеерами, которые видно на экране. Это же нужно чтобы избежать лишних пересозданий. Экономит память.
- есть микроулучшение для low network connection
Результат подается в готовом ввиде.
В общей сумме это увеличивает перфоманс и плавность скролла на 70-85%. А также не проседает при большом кол-во видосов.
Какие рецепты предложили бы вы?
Почему проверка email регекспом — не задача клиента
Сегодня на созвоне комьюнити(делать созвоны на 2 часа в 10 утра субботы я больше не буду) мы обсудили много вопросов про систем дизайн: метрики, компромиссы, архитектуры, много обсуждали BDUI и даже его запроектировали.
Разберём безобидную идею — сложная проверка email на клиентах (iOS/Android/Web) в форме регистрации.
Одно из правил проектирования "Всё, что влияет на безопасность, деньги и целостность данных, обязательно проверять на сервере". Почему?
🟣 Безопасность. Мы можем долго говорить про фишинг и реверс-инжиниринг, но правила проверок всегда видны атакующему. Для почты это не всегда важно, но все же.
🟣 Слишком много реализаций. Три платформы — три реализации. Легко получить расхождения.
🟣 Бизнес правила всегда идут от сервера: формат, уникальность, email/телефон/username, блокировки, инвайты, доступность региона. Это все относится к валидации.
🟣 Единая точка правды. На бэкенде проще логировать попытки, строить алерты, включать капчу
Конечно, не стоит выносить ВСЮ проверку на пробелы, очевидные ошибки на сервер (хотя на проверке это тоже нужно делать). Но валидация на клиенте — это только легкий UX и простые подсказки юзеру.
Не усложняй. Опытный инженер не должен превращать сложность в челендж своих навыков. Вся его большая экспертиза и опыт — обязательны, но для того, чтобы все делать элегантно и просто. Понимать уместность и важность любой дополнительной сложности.
Наша экспертиза не строится на "я всемогущ", а на "я знаю, что нужно". Именно так определяется сложность и навык. Упростить все по максимуму и оставить только необходимую сложность.
Сегодня на созвоне комьюнити
Разберём безобидную идею — сложная проверка email на клиентах (iOS/Android/Web) в форме регистрации.
Одно из правил проектирования "Всё, что влияет на безопасность, деньги и целостность данных, обязательно проверять на сервере". Почему?
Конечно, не стоит выносить ВСЮ проверку на пробелы, очевидные ошибки на сервер (хотя на проверке это тоже нужно делать). Но валидация на клиенте — это только легкий UX и простые подсказки юзеру.
Не усложняй. Опытный инженер не должен превращать сложность в челендж своих навыков. Вся его большая экспертиза и опыт — обязательны, но для того, чтобы все делать элегантно и просто. Понимать уместность и важность любой дополнительной сложности.
Наша экспертиза не строится на "я всемогущ", а на "я знаю, что нужно". Именно так определяется сложность и навык. Упростить все по максимуму и оставить только необходимую сложность.
Please open Telegram to view this post
VIEW IN TELEGRAM
Еще одну тему которую мы обсуждали на прошлом созвоне — это правильные или неправильные ответы на интервью. Что есть редфлаги и как их не допустить не только на собесе, но и в жизни?
Как мы уже определили:
Ключевая метрика сеньора — умение системно мыслить и работать в условиях неопределенности.
Он не ждёт инструкций, а сам формулирует проблему, принимает решения и ведёт проект.
Инженера оценивают не по знанию паттернов и SOLID, а мышлению и способности строить системы. Я собрали и структурировал основные редфлаги инженера.
Статью подробнее c другими примерами можно почитать в закрытом ноушене, но здесь поделюсь основными критериями.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
System Design: Правила декомпозиции при разработке фичи
В прошлом опросе топ 2 тема по интересу — это декомпозиция задачи. И не в том смысле, как поделить задачу в jira-трекере. А как правильно разделить её в коде. И это не про «выбери между очередным MV(X) паттерном». Декомпозиция более обширный термин и зависит от многих переменных.
Например, одно из самых ужасных для меня архитектурных решений — это класть все Service или даже ViewModel в одну папку. Огромный склад всех вьюмоделей, оторванных от своих блоков и бизнес-функций. Или же в VIPER все протоколы в один файл ModuleNameProtocols. Попробуй в этом разберись. Мы даже разбирали отдельный пост 2 года назад.
Вот вам дали разработать чат. С чего начнете? Будете делать шаблонами или оцените ситуацию? Начнете с нетворка или UI?
Многие начинают делать задачу с верстки, но даже когда еще мы читали книгу Mobile System Design, то разбирали — не торопись верстать.
Мы разберем сейчас самую базу, а потом подробнее пройдемся по:
- Layered Architecture
- многомодульной декомпозиции
- UDF декомпозиция
В прошлом опросе топ 2 тема по интересу — это декомпозиция задачи. И не в том смысле, как поделить задачу в jira-трекере. А как правильно разделить её в коде. И это не про «выбери между очередным MV(X) паттерном». Декомпозиция более обширный термин и зависит от многих переменных.
Например, одно из самых ужасных для меня архитектурных решений — это класть все Service или даже ViewModel в одну папку. Огромный склад всех вьюмоделей, оторванных от своих блоков и бизнес-функций. Или же в VIPER все протоколы в один файл ModuleNameProtocols. Попробуй в этом разберись. Мы даже разбирали отдельный пост 2 года назад.
Вот вам дали разработать чат. С чего начнете? Будете делать шаблонами или оцените ситуацию? Начнете с нетворка или UI?
Многие начинают делать задачу с верстки, но даже когда еще мы читали книгу Mobile System Design, то разбирали — не торопись верстать.
Мы разберем сейчас самую базу, а потом подробнее пройдемся по:
- Layered Architecture
- многомодульной декомпозиции
- UDF декомпозиция
2025-10-21 19.39.40.jpg
129 KB
Задачи System Design: Чат, модуль Аналитики, Избранное
В прошлом году мы делали марафон по проектированию. И тогда участвовало почти 100 человек. Я решил что все же можно поделиться контентом оттуда и выбрать самые интересные варианты.
В прошлом году мы делали марафон по проектированию. И тогда участвовало почти 100 человек. Я решил что все же можно поделиться контентом оттуда и выбрать самые интересные варианты.