Зачем нужен BDUI?
Дисклеймер. Стилистически не люблю BDUI за его dev exp, но вкратце обсудим его корни в посте.
Вижу многие заблуждения среди разрабов, блогеров и тп. К счастью или к сожалению, это текущая наша реальность. Никто на прямые вопросы "Как развиваться мобильщику не смотря на текущие тренды с BDUI и АИ?" кроме критики ничего не дают.
Давайте посмотрим как пришел BDUI на рынок и почему такая истерия:
1) Эту тему поднимали еще лет 10 назад, тогда были доклады и всякие статьи как люди пишут свой генератор экранчиков. Тогда такое использовали только в некоторых экранах.
2) год 2022. Те самые события. Удаления из сторов апок многих бигтехов. Как придумать план антикризиса? Вот он и был придуман. Который помогает обходить обновления экранов с бэкенда.
3) Просто поставьте себя на место манагера. Раскатка и обновления нативного кода до пользователя может доходить вместе 2 МЕСЯЦА. Когда же с BDUI — секунды, поменяв конфиг на бэке.
Еще раз. Запуск нативной фичи до юзера — 2 месяца. С BDUI — сегодня.
4) С разработанной инфрой один разраб может закатывать фичи сразу на 3-4 платформы. Я так делал и запускал соло фичи.
Минусы BDUI:
- очень дорого.
- не сделаешь сложные приложения с видео и частыми обновлениями экрана
- сложный порог входа. много незадокументированно. Не описано.
- часто много багов.
Но для манагеров это все чаще ок.
Какие приложения юзают BDUI:
- Авито. Когда я там был нативного кода я писал дай бог 5-10 реквестов в год. В 90% задачах это были огромные конфиги JSON'а
- ОЗОН. Слышал на их конфе, что у них сейчас только BDUI разрабы
- Яндекс Маркет. Там 100% инженеров пишут свой код только на BDUI
- X5. Пока инфы мало, говорят активно пилят свой фреймворк
Лично я ругаю многие BDUI технологии не потому, что мне удобен натив (iOS я правда всем сердцем люблю). А потому, что сам BDUI плохо готовят и мало кто из авторов и разрабов платформы задумывается о тех, кто юзает их технологию. Чаще это promotion driven development, где разрабы думают только о своих целях и метриках, но никто об удобстве. Но я рационально понимаю почему бизнес это хочет. И почему это надо.
Сейчас у нас тренировки по систем дизайну и мы как раз решили познакомиться ближе с этим монстром. Настолько, что сами его запроектируем и изучим изнутри.
Дисклеймер. Стилистически не люблю BDUI за его dev exp, но вкратце обсудим его корни в посте.
Вижу многие заблуждения среди разрабов, блогеров и тп. К счастью или к сожалению, это текущая наша реальность. Никто на прямые вопросы "Как развиваться мобильщику не смотря на текущие тренды с BDUI и АИ?" кроме критики ничего не дают.
Давайте посмотрим как пришел BDUI на рынок и почему такая истерия:
1) Эту тему поднимали еще лет 10 назад, тогда были доклады и всякие статьи как люди пишут свой генератор экранчиков. Тогда такое использовали только в некоторых экранах.
2) год 2022. Те самые события. Удаления из сторов апок многих бигтехов. Как придумать план антикризиса? Вот он и был придуман. Который помогает обходить обновления экранов с бэкенда.
3) Просто поставьте себя на место манагера. Раскатка и обновления нативного кода до пользователя может доходить вместе 2 МЕСЯЦА. Когда же с BDUI — секунды, поменяв конфиг на бэке.
Еще раз. Запуск нативной фичи до юзера — 2 месяца. С BDUI — сегодня.
4) С разработанной инфрой один разраб может закатывать фичи сразу на 3-4 платформы. Я так делал и запускал соло фичи.
Минусы BDUI:
- очень дорого.
- не сделаешь сложные приложения с видео и частыми обновлениями экрана
- сложный порог входа. много незадокументированно. Не описано.
- часто много багов.
Но для манагеров это все чаще ок.
Какие приложения юзают BDUI:
- Авито. Когда я там был нативного кода я писал дай бог 5-10 реквестов в год. В 90% задачах это были огромные конфиги JSON'а
- ОЗОН. Слышал на их конфе, что у них сейчас только BDUI разрабы
- Яндекс Маркет. Там 100% инженеров пишут свой код только на BDUI
- X5. Пока инфы мало, говорят активно пилят свой фреймворк
Лично я ругаю многие BDUI технологии не потому, что мне удобен натив (iOS я правда всем сердцем люблю). А потому, что сам BDUI плохо готовят и мало кто из авторов и разрабов платформы задумывается о тех, кто юзает их технологию. Чаще это promotion driven development, где разрабы думают только о своих целях и метриках, но никто об удобстве. Но я рационально понимаю почему бизнес это хочет. И почему это надо.
Сейчас у нас тренировки по систем дизайну и мы как раз решили познакомиться ближе с этим монстром. Настолько, что сами его запроектируем и изучим изнутри.
Как устроена Мобильная разработка сегодня?
Посмотрел нашумевший ролик от Лехи Гладкова и не понял хейта. Да, многое звучит неприятно и местами грубо, но в этом есть правда.
Я сам начинал с кроссплатформы перед нативом. А до этого писал на php, js, go, react native. Где iOS стала моей пятой или шестой платформой. Натив в моем Тюмени был очень дорогой историей, которую еще в 2018 мало кто мог себе позволить. Более того, были директора кто ненавидел американский айфон всей душой и считал их любителей — позерами.
Может быть, именно это сопротивление в начале пути заставляет держать фокус в канале на нативе. От Hate до Love — one step.
Потому что бизнесу всегда это было интересно. Бизнес не ищет "самый правильный" путь — он ищет самый выгодный.
Поэтому я не понимаю хейта критиков, что PWA, кроссплатформа и BDUI — не интересны бизнесу. Они всегда были интересны. Всегда я спорил и отстаивал на цифрах и метриках что натив нужен. Отрицать привлекательность более дешевых технологий === наивно.
У кроссплатформы есть серьезные минусы из-за которых многие компании свернули отделы:
- сложность поиска сцепов. В нативе чаще проще найти чела, кто гораздо лучше проходит стандартные собесы и не требует миллиарды.
- нет компромиссов и много костылей
- BDUI с нативными компонентами — самый дешевый и лучший аналог любой кроссплатформы
Когда же нужен натив? В красивых апках, со сложной анимацией, большим кол-вом триггеров из сети. Тот же телеграм или чат не сделаешь нормально на кроссплатформе со стабильными 60 фпс.
Именно поэтому я делаю канал еще и про прокачку системного, алгоритмического и продуктового мышления, чтобы разработчик мог думать шире.
Времена сложные. Санкции. Экономика. О каком эстетизме и удобстве идет речь, когда банально у многих компаний стоит цель выжить?
Натив — это круто и здорово, но тут нужно убрать фанатизм, чтобы не было больно.
Нужно много раз задуматься чтобы идти вкатываться в иос разработку, где уже целый год вакансий не стало х2. Уже не станешь только разрабом одной платформы. Это лакшери история, которую нужно ценить и развивать.
Посмотрел нашумевший ролик от Лехи Гладкова и не понял хейта. Да, многое звучит неприятно и местами грубо, но в этом есть правда.
Я сам начинал с кроссплатформы перед нативом. А до этого писал на php, js, go, react native. Где iOS стала моей пятой или шестой платформой. Натив в моем Тюмени был очень дорогой историей, которую еще в 2018 мало кто мог себе позволить. Более того, были директора кто ненавидел американский айфон всей душой и считал их любителей — позерами.
Может быть, именно это сопротивление в начале пути заставляет держать фокус в канале на нативе. От Hate до Love — one step.
Потому что бизнесу всегда это было интересно. Бизнес не ищет "самый правильный" путь — он ищет самый выгодный.
Поэтому я не понимаю хейта критиков, что PWA, кроссплатформа и BDUI — не интересны бизнесу. Они всегда были интересны. Всегда я спорил и отстаивал на цифрах и метриках что натив нужен. Отрицать привлекательность более дешевых технологий === наивно.
У кроссплатформы есть серьезные минусы из-за которых многие компании свернули отделы:
- сложность поиска сцепов. В нативе чаще проще найти чела, кто гораздо лучше проходит стандартные собесы и не требует миллиарды.
- нет компромиссов и много костылей
- BDUI с нативными компонентами — самый дешевый и лучший аналог любой кроссплатформы
Когда же нужен натив? В красивых апках, со сложной анимацией, большим кол-вом триггеров из сети. Тот же телеграм или чат не сделаешь нормально на кроссплатформе со стабильными 60 фпс.
Именно поэтому я делаю канал еще и про прокачку системного, алгоритмического и продуктового мышления, чтобы разработчик мог думать шире.
Времена сложные. Санкции. Экономика. О каком эстетизме и удобстве идет речь, когда банально у многих компаний стоит цель выжить?
Натив — это круто и здорово, но тут нужно убрать фанатизм, чтобы не было больно.
Нужно много раз задуматься чтобы идти вкатываться в иос разработку, где уже целый год вакансий не стало х2. Уже не станешь только разрабом одной платформы. Это лакшери история, которую нужно ценить и развивать.
YouTube
Как устроена Мобильная разработка сегодня? | Алексей Гладков #64
В выпуске мы поговорили с Алексеем Гладковым, создателем канала Mobile Developer, инженером с 13+ годами опыта под Android и iOS. Обсудили как менялась мобилка изнутри: от Java и XML до Kotlin, Compose и серверного UI, и выяснили, почему эпоха “нативных…
Яндекс меняет процесс найма
В авито я был в инициативной группе тех, кто помогал улучшить собесы. Лично я старался обновить и дополнить алгоритмическую секцию и платформенную iOS. Да и в целом активно собесил и в общем провел около 100 секций. Может быть кто-то даже попал на мои собесы.
Здесь есть много вопросов, которые нужно держать в голове: метрики time-to-hire и time-to-offer, чтобы сложные собесы не затянулись на месяцы. Ротацию задач. Их адекватность и реальную пользу. Мы проводили опросы среди других интервьюеров, ходили к нанимающим менеджерам, меняли задачи, улучшали процесс. Старались чтобы каждый был справедливо оценен нами и нанимающими манагерами.
В крупных компаниях, где в день по 100 собесов, это очень важно. Из 100 человек доходит до финала обычно только 20. А доходят они бывает только спустя 30-40 дней с момента контакта с hr. Вот и яндекс решил актуализировать свой процесс
Нет, алгосекции не убрали. Но добавили новый этап — оценка опыта
Подробнее о ней писал CTO Лавки
UPD: для мобил нет блока с опытом
В авито я был в инициативной группе тех, кто помогал улучшить собесы. Лично я старался обновить и дополнить алгоритмическую секцию и платформенную iOS. Да и в целом активно собесил и в общем провел около 100 секций. Может быть кто-то даже попал на мои собесы.
Здесь есть много вопросов, которые нужно держать в голове: метрики time-to-hire и time-to-offer, чтобы сложные собесы не затянулись на месяцы. Ротацию задач. Их адекватность и реальную пользу. Мы проводили опросы среди других интервьюеров, ходили к нанимающим менеджерам, меняли задачи, улучшали процесс. Старались чтобы каждый был справедливо оценен нами и нанимающими манагерами.
В крупных компаниях, где в день по 100 собесов, это очень важно. Из 100 человек доходит до финала обычно только 20. А доходят они бывает только спустя 30-40 дней с момента контакта с hr. Вот и яндекс решил актуализировать свой процесс
Нет, алгосекции не убрали. Но добавили новый этап — оценка опыта
Секция про опыт позволяет провалидировать навыки техлида, которые сложно проверить только кодовой или архитектурной задачкой.
Подробнее о ней писал CTO Лавки
Тип секций Bar raising помогает повысить объективность оценивания и скомпенсировать неопытность некоторых интервьюверов. Где-то можно снизить вес очевидно случайно проваленной секции (дали слишком лютую задачку, или она просто не зашла, хотя по прочим секциям скилл виден), а где-то, наоборот, не допустить откровенно компромиссный найм (при наличии ред-флагов, которые бар-рейзер видит с высоты своего опыта, или если все секции пройдены прям "на тоненького").
UPD: для мобил нет блока с опытом
BDUI vs WebView
В комментах прошлого поста спросили: "Зачем нужен BDUI, если есть WebView?".
И это один из хороших вопросов.
Я встречал приложения, которые были написаны на WebView бэкендерами, а потом переписывались на натив. Основные причины:
1️⃣ Нативный опыт
WebView — это минибраузер со своим движком. Он обрезан и еще выглядит плохо. Можно конечно вложиться, чтобы UI выглядил достойно, но чаще это эквилибристика между скиллом и дизайном.
Но тот же скролл в WebView выглядит неестественно. А JS задержки создают доп проблемы. Импут лаг натива намного красивее.
На слабых устройствах перфоманс сложного лайаута WebView упадет на дно.
По сути BDUI это тот же браузер, но который управляет нативной версткой.
2️⃣ Безопасность.
В целом всякие переходы в вебвью и инъекции — это доп геморой. В нем намного легче украсть токены, данные, подменить интерфейс и код. Можно конечно заморочиться с доп сертификатами и защитой, но это сложно, неудобно и дорого.
А с нормальными логами можно попрощаться.
3️⃣ Глубокая интеграция с приложением
Прямой доступ ко всем функциям в BDUI (ведь это тот же натив).
В вебвью очень сложно работать с:
- доступностью
- платформенными анимациями
- навигацией
- кастомными пушами
- системными жестами
- темы и кастомизация
- использовать нативные стэки
- работать с датчиками устройства
И многое другое. Это основные причины, почему уже +- зрелое приложение уходит от WebView или PWA.
На скриншоте схема MVP BDUI, которую мы рисовали на тренировках по систем дизайну. Рисовал ее я. Меня внезапно собесили.
В комментах прошлого поста спросили: "Зачем нужен BDUI, если есть WebView?".
И это один из хороших вопросов.
Я встречал приложения, которые были написаны на WebView бэкендерами, а потом переписывались на натив. Основные причины:
1️⃣ Нативный опыт
WebView — это минибраузер со своим движком. Он обрезан и еще выглядит плохо. Можно конечно вложиться, чтобы UI выглядил достойно, но чаще это эквилибристика между скиллом и дизайном.
Но тот же скролл в WebView выглядит неестественно. А JS задержки создают доп проблемы. Импут лаг натива намного красивее.
На слабых устройствах перфоманс сложного лайаута WebView упадет на дно.
По сути BDUI это тот же браузер, но который управляет нативной версткой.
2️⃣ Безопасность.
В целом всякие переходы в вебвью и инъекции — это доп геморой. В нем намного легче украсть токены, данные, подменить интерфейс и код. Можно конечно заморочиться с доп сертификатами и защитой, но это сложно, неудобно и дорого.
А с нормальными логами можно попрощаться.
3️⃣ Глубокая интеграция с приложением
Прямой доступ ко всем функциям в BDUI (ведь это тот же натив).
В вебвью очень сложно работать с:
- доступностью
- платформенными анимациями
- навигацией
- кастомными пушами
- системными жестами
- темы и кастомизация
- использовать нативные стэки
- работать с датчиками устройства
И многое другое. Это основные причины, почему уже +- зрелое приложение уходит от WebView или PWA.
На скриншоте схема MVP BDUI, которую мы рисовали на тренировках по систем дизайну. Рисовал ее я. Меня внезапно собесили.
Forwarded from The Экономист
Российских студентов начали обучать программированию на кириллице. В Пензенском госуниверситете преподаватели адаптировали JavaScript, полностью переведя синтаксис и задания на русский язык. По словам разработчиков, проект призван уменьшить зависимость от англоязычных стандартов.
🤑 The Экономист
Please open Telegram to view this post
VIEW IN TELEGRAM
Какое мобильное приложение яндекса самое лучшее?
Anonymous Poll
34%
Яндекс Музыка
16%
Яндекс Го
17%
Кинопоиск
3%
Яндекс Браузер
7%
Яндекс Еда 🖤
0%
Домиленд
3%
Яндекс Маркет
5%
Лавка
38%
Яндекс Карты
17%
Другое
Mobile System Design
Сегодня у меня день рождения и мы набрали 100 лайков.
Этот канал всегда был моим проектом для души. Я никогда не покупал рекламу. Не просился на коллабы. Не накручивал лайки, подписчиков, опыт и заслуги. Мне всегда важна органика.
Искренность. Мне важна чистота и правдивость метрик для деббага.
Я начинал писать статьи на хабре и так все закрутилось, что вырос этот канал. Теперь стараюсь и читателей благодаратить контентом.
Написал статью про систем дизайн. Можете почитать на выходных.
Сегодня у меня день рождения и мы набрали 100 лайков.
Этот канал всегда был моим проектом для души. Я никогда не покупал рекламу. Не просился на коллабы. Не накручивал лайки, подписчиков, опыт и заслуги. Мне всегда важна органика.
Искренность. Мне важна чистота и правдивость метрик для деббага.
Я начинал писать статьи на хабре и так все закрутилось, что вырос этот канал. Теперь стараюсь и читателей благодаратить контентом.
Написал статью про систем дизайн. Можете почитать на выходных.
Хабр
Mobile System Design
Mobile System Design — один из главных навыков мобильного инженера. В реальной практике или на собесе это определят твою сеньорность. Компании проводят секции с оценками. Указывают навык в матрице...
1
Как писать юнит-тесты на многопоточный код
Следующий месяц будет преимущественно про Advanced Swift Concurrency + Swift 6:
🔘 Порешаем самые интересные задачи
🔘 изучим не только плюсы, но и глубже познакомимся с проблемами
🔘 сразу перейдем к практике и задачам
🔘 и многое другое
Начнем со статьи с интересной темой — написание юнит тестов с многопточным кодом. Почему это важно:
- меня пару раз просили на собесах писать тест именно на многопоточный код. И не всегда оптимальное решение приходит сразу в голову
- не все пишут такие тесты в реальных проектах из-за страха флаки тестов, хотя писать их супер важно.
Следующий месяц будет преимущественно про Advanced Swift Concurrency + Swift 6:
Начнем со статьи с интересной темой — написание юнит тестов с многопточным кодом. Почему это важно:
- меня пару раз просили на собесах писать тест именно на многопоточный код. И не всегда оптимальное решение приходит сразу в голову
- не все пишут такие тесты в реальных проектах из-за страха флаки тестов, хотя писать их супер важно.
Please open Telegram to view this post
VIEW IN TELEGRAM
DEV Community
Deterministic Unit Tests in Swift Concurrency
Introduction Testing code that leverages Swift Concurrency can be challenging, especially...
Forwarded from Московский кэш
📥 RuStore может появиться на iPhone
В тестовой версии нашли функцию RuStore Bridge, которая позволит устанавливать приложения из RuStore на iPhone через подключение к Android-смартфону по USB.
В тестовой версии нашли функцию RuStore Bridge, которая позволит устанавливать приложения из RuStore на iPhone через подключение к Android-смартфону по USB.
На каком стэке преимущественно (>60% кода за последний месяц) вы пишите текущий проект?
Anonymous Poll
31%
UIKit + GCD
25%
UIKit + Swift Councurrency
34%
SwiftUI + Swift Councurrency
5%
SwiftUI + GCD
14%
SwiftUI + Combine
6%
Кроссплатформа
7%
BDUI
8%
UIKit + Combine
8%
Другое
A deep dive into Collections, Sequences, and Iterators in Swift
Походу Donny Wals читает наш канал, хоть и с опозданием. Ведь еще в феврале была серия постов как мы писали свою потокобезопасную коллекцию тут, тут и тут
Донни считает что знать это полезно потому что:
- Понимание Sequence и Collection помогает писать структуры или расширять существующие с правильной семантикой
- Знание как работет под капотом for in помогает предвидеть проблемы с производительностью или безопасностью
Когда я работал в Авито Финтехе, то это помогло мне в задаче из практики: тогда мне нужно было сделать историю операций. Ну как в банках где показано куда и когда вы что-то получали и оплачивали.
Нужно было пагинировано загружать блоки. Обычный массив мне показалось скучно. Да и планов на этот экран было много: обновлять через вебсокеты и делать это интерактивно. Выгружать данные из CSV. Добавлять сложные запросы. Подписки, баланс, статусы перевод. Короче, хз че как там сейчас. Но экран был потенциально амбициозный (а как еще эффективно продать разработку разрабам).
Я решил запроектировать и написать свою коллекцию TransactionsHistory, а для универсальных транзакций заюзать какой-нибудь WalletActivityStream (AsyncSequence).
Почему не подходил обычный массив?
- Ну, массиву нужно знать заранее сколько памяти хранить. Это не всегда эффективно по памяти.
- Копируется при мутации (CoW). Мутации требуют перераспределения данных
- Большие массивы === большой риск Out Of Memory
- Нет асинхронной семантики
- Нет ленивой выборки
Если у пользователя 20 000 транзакций — в память загружается весь буфер. Если пришла новая операция, то массив нужно пересоздавать или вставлять, а это потенциально капец как дорого. Статус платежа изменился? Снова изменение коллекции. Ну и вот такие детали помогают лучше понимать когда нужна коллекция, а когда стрим.
Так сделал ли я в итоге крутую коллекцию? Отложил после MVP😂
Походу Donny Wals читает наш канал, хоть и с опозданием. Ведь еще в феврале была серия постов как мы писали свою потокобезопасную коллекцию тут, тут и тут
Донни считает что знать это полезно потому что:
- Понимание Sequence и Collection помогает писать структуры или расширять существующие с правильной семантикой
- Знание как работет под капотом for in помогает предвидеть проблемы с производительностью или безопасностью
Когда я работал в Авито Финтехе, то это помогло мне в задаче из практики: тогда мне нужно было сделать историю операций. Ну как в банках где показано куда и когда вы что-то получали и оплачивали.
Нужно было пагинировано загружать блоки. Обычный массив мне показалось скучно. Да и планов на этот экран было много: обновлять через вебсокеты и делать это интерактивно. Выгружать данные из CSV. Добавлять сложные запросы. Подписки, баланс, статусы перевод. Короче, хз че как там сейчас. Но экран был потенциально амбициозный (а как еще эффективно продать разработку разрабам).
Я решил запроектировать и написать свою коллекцию TransactionsHistory, а для универсальных транзакций заюзать какой-нибудь WalletActivityStream (AsyncSequence).
Почему не подходил обычный массив?
- Ну, массиву нужно знать заранее сколько памяти хранить. Это не всегда эффективно по памяти.
- Копируется при мутации (CoW). Мутации требуют перераспределения данных
- Большие массивы === большой риск Out Of Memory
- Нет асинхронной семантики
- Нет ленивой выборки
Если у пользователя 20 000 транзакций — в память загружается весь буфер. Если пришла новая операция, то массив нужно пересоздавать или вставлять, а это потенциально капец как дорого. Статус платежа изменился? Снова изменение коллекции. Ну и вот такие детали помогают лучше понимать когда нужна коллекция, а когда стрим.
Так сделал ли я в итоге крутую коллекцию? Отложил после MVP
Please open Telegram to view this post
VIEW IN TELEGRAM
Donny Wals
A deep dive into Collections, Sequences, and Iterators in Swift – Donny Wals
When you write the compiler quietly sets a lot of machinery in motion. Usually writing a for loop is a pretty mundane task, it’s not that complex of a syntax to write. However, it’s always fun to dig…
Мы снова глубоко погружаемся в Swift Concurrency. На канале было много теории и практики — но этого все равно мало.
Хочется услышать опыт инженера, который прошел этот путь в проде: переписывал и лидировал проекты, сталкивался с подводными камнями и точно знает, что работает, а что нет.
В выпуске он поделился:
Этого не расскажет чатгпт!
В конце месяца сделаем тренировки по SC и порешаем реальные задачи.
Получить доступ по скидке
Please open Telegram to view this post
VIEW IN TELEGRAM
The price of mandatory code reviews
Холливара перед выходными.
Код ревью переоценено. Во многих компаниях в этот процесс вкладывают больше, чем он может дать. Иногда ошибочно считая что только детальное и дотошное ревью помогает обеспечить наивысшее качество проекта. А еще хуже когда внедряют метрику "сколько ты сделал комментариев реквестам". Так некоторые эксперты искусственно создают свою значимость и отказываются от движения вперед.
Для меня код ревью теряет ценность и становится каким-то около формально-бюрократичным процессом во многих компаниях. Я выделяю несколько причин:
- слишком большой поток реквестов и ревьюеров размывает ответственность и не дает нормально вчитываться
- сложные и большие реквесты даже если ревьюится, то уже поздно на что-то глобально влиять. Код написан. Ты не можешь развернуть разраба и приходится идти на компромиссы. Тут лучше справляется арх ревью, а не код ревью
- в крутых командах высокое доверие. Если тебе нужно выделять час времени и писать 30-40 комментов своему коллеги, то проблема сидит глубже.
- в больших компаниях и командах кодревью почти условное из-за огромного кол-ва велосипедов, BDUI, кроссплатформ и тп. У тебя не хватает экспертов кто также хорошо разбирается в том, в чем разбираешься ты
Вот и автор приводит данные: сравнение команд, где код-ревью обязательны, и тех, где их нет или они используются по желанию.
- Команды без обязательных ревью работают быстрее, но выпускают больше багов
- Команды с обязательными ревью имеют меньше багов, но могут быть медленнее
Вывод автора: обязательные ревью — не универсальное решение. Он предлагает: пусть ревью будут выборочными, качественными и быстрыми.
Кодревью нужно, но оно не должно быть только одним процессом качества. Гораздо лучше помогают:
- автотесты при разработке
- архревью перед разработкой больших задач
- аи тулкиты могут снизить рутину и уже неплохо подсвечивают критические и грубые ошибки
- парное программирование
Холливара перед выходными.
Код ревью переоценено. Во многих компаниях в этот процесс вкладывают больше, чем он может дать. Иногда ошибочно считая что только детальное и дотошное ревью помогает обеспечить наивысшее качество проекта. А еще хуже когда внедряют метрику "сколько ты сделал комментариев реквестам". Так некоторые эксперты искусственно создают свою значимость и отказываются от движения вперед.
Для меня код ревью теряет ценность и становится каким-то около формально-бюрократичным процессом во многих компаниях. Я выделяю несколько причин:
- слишком большой поток реквестов и ревьюеров размывает ответственность и не дает нормально вчитываться
- сложные и большие реквесты даже если ревьюится, то уже поздно на что-то глобально влиять. Код написан. Ты не можешь развернуть разраба и приходится идти на компромиссы. Тут лучше справляется арх ревью, а не код ревью
- в крутых командах высокое доверие. Если тебе нужно выделять час времени и писать 30-40 комментов своему коллеги, то проблема сидит глубже.
- в больших компаниях и командах кодревью почти условное из-за огромного кол-ва велосипедов, BDUI, кроссплатформ и тп. У тебя не хватает экспертов кто также хорошо разбирается в том, в чем разбираешься ты
Вот и автор приводит данные: сравнение команд, где код-ревью обязательны, и тех, где их нет или они используются по желанию.
- Команды без обязательных ревью работают быстрее, но выпускают больше багов
- Команды с обязательными ревью имеют меньше багов, но могут быть медленнее
Вывод автора: обязательные ревью — не универсальное решение. Он предлагает: пусть ревью будут выборочными, качественными и быстрыми.
Кодревью нужно, но оно не должно быть только одним процессом качества. Гораздо лучше помогают:
- автотесты при разработке
- архревью перед разработкой больших задач
- аи тулкиты могут снизить рутину и уже неплохо подсвечивают критические и грубые ошибки
- парное программирование
newsletter.manager.dev
The price of mandatory code reviews
Challenging the unwritten law of software engineering
Servant Leadership
Не все идеи agile и scrum я поддерживаю. Но некоторые очень нравятся. Например идея о сервант-лидерстве. Есть в ней что-то самурайское.
Почему-то в современном мире любая мысль "думать о других, а не о себе" высмеивается и считается куколдизмом. Мне это сложно понять и я считаю это незрелой позицией. Особенно когда многие результаты можно добиться только командной игрой, где важно доверие и поддержка.
Не все идеи agile и scrum я поддерживаю. Но некоторые очень нравятся. Например идея о сервант-лидерстве. Есть в ней что-то самурайское.
Сервант-лидерство = “служить, чтобы вести”: лидер ставит успех людей выше личных заслуг, действует с позиции скромности и не "забирает" себе победы команды. Ключевые принципы: доверие, эмпатия, сотрудничество и этичное использование влияния; лидер «ведёт из-за спины», убирая препятствия и помогая самоорганизации.
Это стиль для лидеров в команде — фокус на создании условий, в которых команда сама принимает решения и растёт.
Почему-то в современном мире любая мысль "думать о других, а не о себе" высмеивается и считается куколдизмом. Мне это сложно понять и я считаю это незрелой позицией. Особенно когда многие результаты можно добиться только командной игрой, где важно доверие и поддержка.
DivKit
Почти каждый яндексоид знает что это за зверь. Да что там яндексоид, я до яндекса слышал о нем разное... Среди каналов и разрабов, кто не работал с BDUI, есть много мифов и заблуждений.
Будто App Store может тебя заблокировать из-за этого или что BDUI развитие только в СНГ (где удаляют прилы). Но почти все фаанг компании написали и юзают по паре таких технологий. Тот же Facebook*(осуждаем и порицаем) и апки гугла почти все на BDUI.
А в СНГ это Авито, Озон, Х5, Маркет.
На тренировках по систем дизайну мы разбирали BDUI. Где я во многом опирался на общие практики.
Как это работает:
- Сервер формирует JSON (карточку/экран) — руками или через json-builder.
- Клиент получает JSON и отдаёт его див-рендереру (DivView), который строит нативную иерархию.
- Интерактивность описывается в JSON: состояния, анимации переходов, обработчики действий, переменные.
Самое важное что пишется в самой доке это рекомендации когда юзать DivKit, а когда нет. На мой взгляд это отличный чеклист для всех BDUI:
- Нужно часто менять интерфейс без публикации в сторах
- Хочется единый контракт на UI между iOS/Android/Web
Когда не нужно использовать:
- Экран редко меняется, а весь продукт — чисто нативный без SDUI-процессов
- Команда/процессы не готовы поддерживать контракты и версии между клиентом и сервером
- Когда нужны сложные анимации и красивый UI
Ставь 🖤 если нравится BDUI
и💀 если нет
Почти каждый яндексоид знает что это за зверь. Да что там яндексоид, я до яндекса слышал о нем разное... Среди каналов и разрабов, кто не работал с BDUI, есть много мифов и заблуждений.
Будто App Store может тебя заблокировать из-за этого или что BDUI развитие только в СНГ (где удаляют прилы). Но почти все фаанг компании написали и юзают по паре таких технологий. Тот же Facebook*(осуждаем и порицаем) и апки гугла почти все на BDUI.
А в СНГ это Авито, Озон, Х5, Маркет.
DivKit — это фреймворка для BDUI. Это позволяет менять экран без релиза приложения и переиспользовать код и настройки UI между платформами. Под капотом — общий JSON, набор рендереров для клиентов и утилиты для генерации/сборки JSON на сервере.
На тренировках по систем дизайну мы разбирали BDUI. Где я во многом опирался на общие практики.
Как это работает:
- Сервер формирует JSON (карточку/экран) — руками или через json-builder.
- Клиент получает JSON и отдаёт его див-рендереру (DivView), который строит нативную иерархию.
- Интерактивность описывается в JSON: состояния, анимации переходов, обработчики действий, переменные.
Самое важное что пишется в самой доке это рекомендации когда юзать DivKit, а когда нет. На мой взгляд это отличный чеклист для всех BDUI:
- Нужно часто менять интерфейс без публикации в сторах
- Хочется единый контракт на UI между iOS/Android/Web
Когда не нужно использовать:
- Экран редко меняется, а весь продукт — чисто нативный без SDUI-процессов
- Команда/процессы не готовы поддерживать контракты и версии между клиентом и сервером
- Когда нужны сложные анимации и красивый UI
Ставь 🖤 если нравится BDUI
и
Please open Telegram to view this post
VIEW IN TELEGRAM
DivKit
DivKit — Кроссплатформенный фреймворк для Server-driven UI с открытым кодом
TaskLocal в Swift
В нашем воркшопе по Swift Concurrency + Swift 6 Савва немного прошелся по TaskLocal. Подметив, что это интересная, но редкая механика языка. Я даже пошел копаться в последних проектах и не нашел ни одного использования.
Представь, что у тебя куча асинхронных задач. Каждой нужен свой контекст — ID запроса, логгер, настройки. Как решать эту задачу?
Пробрасывать через параметры? Замусорено при большом кол-ве.
Глобальная переменная? Гонка данных. TaskLocal — элегантное решение.
Данные доступны везде внутри этой задачи и ее детей, но не видны другим задачам.
Ситуация: Пользователь делает запрос к серверу. Ты хочешь логировать всё, что происходит с этим запросом — куда ходили, что упало, сколько времени заняло.
🧬 Без TaskLocal: контекст либо глобальный, либо прокидываешь через 100500 параметров.
💎 С TaskLocal: каждая задача живет в своем контексте с данными, которые видны всем внутри, но изолированы от других задач.
Это как номер заказа в ресторане — официант не таскает бумажку с номером, но всегда знает, какой заказ обслуживает. Другие официанты со своими заказами ему не мешают.
В нашем воркшопе по Swift Concurrency + Swift 6 Савва немного прошелся по TaskLocal. Подметив, что это интересная, но редкая механика языка. Я даже пошел копаться в последних проектах и не нашел ни одного использования.
Представь, что у тебя куча асинхронных задач. Каждой нужен свой контекст — ID запроса, логгер, настройки. Как решать эту задачу?
Пробрасывать через параметры? Замусорено при большом кол-ве.
Глобальная переменная? Гонка данных. TaskLocal — элегантное решение.
Данные доступны везде внутри этой задачи и ее детей, но не видны другим задачам.
Ситуация: Пользователь делает запрос к серверу. Ты хочешь логировать всё, что происходит с этим запросом — куда ходили, что упало, сколько времени заняло.
Это как номер заказа в ресторане — официант не таскает бумажку с номером, но всегда знает, какой заказ обслуживает. Другие официанты со своими заказами ему не мешают.
Please open Telegram to view this post
VIEW IN TELEGRAM
Референсы про продуктовое мышление vs. проектное мышление
Я давно работаю в продуктовых командах и большую часть пути прошел именно в продуктовых компаниях. Навык искать бизнес-ценность у меня формировался ещё в Авито, там это отдельный пункт в матрице компетенций, и без него расти действительно сложно. Если нет ориентации на оуткамы, то и движение вперед ощущается иначе.
Ещё раньше одним из главных источников идей для меня был канал @product_developer. Так вышло, что Никита, автор канала, позже стал моим лидом — и у него есть много сильных материалов на тему продуктового подхода. Некоторые из его постов я часто пересылаю и сам регулярно пишу на темы вроде:
- продуктовое мышление в разработке,
- бизнес-заинтересованность инженера,
- как стать сильным инженером.
Сейчас вижу, как этот подход постепенно становится массовым. Порой даже появляется забавный "race condition": кто же первым в 2025 начал говорить об инженерной продуктовой заинтересованности? (но ведь об этом мы в канале говорим с 2022)
Иногда, когда я поднимаю эти темы (а пишу о них уже несколько лет), другие каналы ошибочно думают, что я ссылаюсь именно на них. Но здесь важно помнить простую вещь: прежде чем считать какую-то мысль своей уникальной, стоит проверить недавние публикации коллег. И может быть окажется что ты сам окажешься лишь поверхностной копией и кратким пересказом, который не понимает масштабов и глубин тем своих коллег.
Такое бывает, когда изучаешь тему поверхностно, кажется, что идея пришла сама собой. И легко не заметить, что у нее уже есть источник, где эта мысль была разобрана глубже и качественнее. Недостаточная глубина погружения иногда искажает ощущение "первооткрывательства". Создает пьянящую иллюзию, что твой микро-твит стал главным вдохновителем среди тонны контента, качеством в разы лучше твоего.
Кстати, всякие LLMки круто помогают сделать погружения глубже.
Я давно работаю в продуктовых командах и большую часть пути прошел именно в продуктовых компаниях. Навык искать бизнес-ценность у меня формировался ещё в Авито, там это отдельный пункт в матрице компетенций, и без него расти действительно сложно. Если нет ориентации на оуткамы, то и движение вперед ощущается иначе.
Ещё раньше одним из главных источников идей для меня был канал @product_developer. Так вышло, что Никита, автор канала, позже стал моим лидом — и у него есть много сильных материалов на тему продуктового подхода. Некоторые из его постов я часто пересылаю и сам регулярно пишу на темы вроде:
- продуктовое мышление в разработке,
- бизнес-заинтересованность инженера,
- как стать сильным инженером.
Сейчас вижу, как этот подход постепенно становится массовым. Порой даже появляется забавный "race condition": кто же первым в 2025 начал говорить об инженерной продуктовой заинтересованности? (но ведь об этом мы в канале говорим с 2022)
Иногда, когда я поднимаю эти темы (а пишу о них уже несколько лет), другие каналы ошибочно думают, что я ссылаюсь именно на них. Но здесь важно помнить простую вещь: прежде чем считать какую-то мысль своей уникальной, стоит проверить недавние публикации коллег. И может быть окажется что ты сам окажешься лишь поверхностной копией и кратким пересказом, который не понимает масштабов и глубин тем своих коллег.
Такое бывает, когда изучаешь тему поверхностно, кажется, что идея пришла сама собой. И легко не заметить, что у нее уже есть источник, где эта мысль была разобрана глубже и качественнее. Недостаточная глубина погружения иногда искажает ощущение "первооткрывательства". Создает пьянящую иллюзию, что твой микро-твит стал главным вдохновителем среди тонны контента, качеством в разы лучше твоего.
Кстати, всякие LLMки круто помогают сделать погружения глубже.
Telegram
iOS Makes Me Hate
Продукт vs проект, и в чем разница для разработчика.
Представим проект по постройке дома на заказ. Есть чертежи, есть план работ, сроки. Всё посчитано, всё оптимально. Берешь ресурсы, делаешь по плану, в срок сдаешь дом. Звучит просто.
На деле все проекты…
Представим проект по постройке дома на заказ. Есть чертежи, есть план работ, сроки. Всё посчитано, всё оптимально. Берешь ресурсы, делаешь по плану, в срок сдаешь дом. Звучит просто.
На деле все проекты…
Недавно в опросе выяснилось, что почти 58% из 678 участников уже используют Swift Concurrency в реальных проектах. Это впечатляет. Но при этом практических материалов почти нет — в основном лишь пересказы документации или обзоры базовых концепций.
Отдельный феномен — реакция некоторых авторов. Достаточно в большом материале случайно повторить пару слов из их микротвитов и репостов чужих материалов, и уже можно получить обвинение в "копировании". Или в непрофессиональной этике, когда ты опубликовал похожую чужую статью "слишком рано", ведь эту статью они опубликовали первыми. Правила этой игры я не понимаю, когда ты бежишь не за репостами, а за шарингом знаний. Особенно если статья чужая. Но когда вы приходили в лс и говорили что копируюте идею с бусти и приложением я молчал
Забавно наблюдать претензии на оригинальность от каналов, которые сами просто пересказывают статьи. Если сомневаетесь, оцените уникальность любого любимого канала через чатгпт — иллюзии быстро рассеиваются. Я так регулярно делаю и для себя.
Но я не хочу превращать свой канал в ежедневный агрегатор чужих постов. Мне важнее другое — окружать себя людьми сильнее меня, брать опыт у реальных практиков и двигать индустрию, которая на фоне AI стремительно меняется. Мне нужны оффлайн тренировки, а не наблюдения как тренируются другие. Интервью, советы, разборы, консультации, созвоны — все это дает живой опыт и держит меня в тонусе. В такой среде работают правила спортивной конкуренции: высокий темп, постоянное развитие. Изоляция же ведет к застою и фантазиям, оторванным от реальности.
В ежедневной работе у меня хватает задач: оптимизация рендеринга, продумывание многопоточности для тяжёлых вычислений, работа с адаптацией под разные скорости сети. Проект позволяет почти не цепляться за легаси и использовать Swift Concurrency по полной.
Вот Миша Рубанов подсветил, что нужно обязательно отменять загрузку контента если ты решил его скрыть в ленте, это очень важная база о которой часто забывают думая отмена происходит автоматом. Но та же загрузка видосов может быть очень тяжеловесной операцией и в разных странах бывает разная скорость интернета.
В этой подборке я начал с классических задач:
Кстати, я все чаще думаю выделять пару часов в неделю на создание видеороликов с разбором практики и лайфкодинга. Ставь
А в закрытой базе мы собираем самые практические задачи
Please open Telegram to view this post
VIEW IN TELEGRAM
2