Как AI меняет экономику мобильных приложений

Увидел еще одну статью у моих коллег про закат кроссплатформы.

Вкратце о чем статья:
- кроссплатформа теряет преимущества. Теперь АИ тулкиты нивелирует ее сильные стороны.
- кроссплатформа может быть не нужна,
если AI уже делает разработку быстрее и дешевле даже в нативных

Как думаете, останутся ли отдельные роли или с приходом им мы станем универсалами?

Зачем нужен 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, где разрабы думают только о своих целях и метриках, но никто об удобстве. Но я рационально понимаю почему бизнес это хочет. И почему это надо.

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

Как устроена Мобильная разработка сегодня?

Посмотрел нашумевший ролик от Лехи Гладкова и не понял хейта. Да, многое звучит неприятно и местами грубо, но в этом есть правда.

Я сам начинал с кроссплатформы перед нативом. А до этого писал на php, js, go, react native. Где iOS стала моей пятой или шестой платформой. Натив в моем Тюмени был очень дорогой историей, которую еще в 2018 мало кто мог себе позволить. Более того, были директора кто ненавидел американский айфон всей душой и считал их любителей — позерами.

Может быть, именно это сопротивление в начале пути заставляет держать фокус в канале на нативе. От Hate до Love — one step.

Потому что бизнесу всегда это было интересно. Бизнес не ищет "самый правильный" путь — он ищет самый выгодный.

Поэтому я не понимаю хейта критиков, что PWA, кроссплатформа и BDUI — не интересны бизнесу. Они всегда были интересны. Всегда я спорил и отстаивал на цифрах и метриках что натив нужен. Отрицать привлекательность более дешевых технологий === наивно.

У кроссплатформы есть серьезные минусы из-за которых многие компании свернули отделы:
- сложность поиска сцепов. В нативе чаще проще найти чела, кто гораздо лучше проходит стандартные собесы и не требует миллиарды.
- нет компромиссов и много костылей
- BDUI с нативными компонентами — самый дешевый и лучший аналог любой кроссплатформы

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

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

Времена сложные. Санкции. Экономика. О каком эстетизме и удобстве идет речь, когда банально у многих компаний стоит цель выжить?

Натив — это круто и здорово, но тут нужно убрать фанатизм, чтобы не было больно.

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

Яндекс меняет процесс найма

В авито я был в инициативной группе тех, кто помогал улучшить собесы. Лично я старался обновить и дополнить алгоритмическую секцию и платформенную iOS. Да и в целом активно собесил и в общем провел около 100 секций. Может быть кто-то даже попал на мои собесы.

Здесь есть много вопросов, которые нужно держать в голове: метрики time-to-hire и time-to-offer, чтобы сложные собесы не затянулись на месяцы. Ротацию задач. Их адекватность и реальную пользу. Мы проводили опросы среди других интервьюеров, ходили к нанимающим менеджерам, меняли задачи, улучшали процесс. Старались чтобы каждый был справедливо оценен нами и нанимающими манагерами.

В крупных компаниях, где в день по 100 собесов, это очень важно. Из 100 человек доходит до финала обычно только 20. А доходят они бывает только спустя 30-40 дней с момента контакта с hr. Вот и яндекс решил актуализировать свой процесс

Нет, алгосекции не убрали. Но добавили новый этап — оценка опыта

Секция про опыт позволяет провалидировать навыки техлида, которые сложно проверить только кодовой или архитектурной задачкой.

Подробнее о ней писал CTO Лавки

Тип секций Bar raising помогает повысить объективность оценивания и скомпенсировать неопытность некоторых интервьюверов. Где-то можно снизить вес очевидно случайно проваленной секции (дали слишком лютую задачку, или она просто не зашла, хотя по прочим секциям скилл виден), а где-то, наоборот, не допустить откровенно компромиссный найм (при наличии ред-флагов, которые бар-рейзер видит с высоты своего опыта, или если все секции пройдены прям "на тоненького").

UPD: для мобил нет блока с опытом

Mobile System Design

Сегодня у меня день рождения и мы набрали 100 лайков.

Этот канал всегда был моим проектом для души. Я никогда не покупал рекламу. Не просился на коллабы. Не накручивал лайки, подписчиков, опыт и заслуги. Мне всегда важна органика.

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

Я начинал писать статьи на хабре и так все закрутилось, что вырос этот канал. Теперь стараюсь и читателей благодаратить контентом.

Написал статью про систем дизайн. Можете почитать на выходных.

The price of mandatory code reviews

Холливара перед выходными.

Код ревью переоценено. Во многих компаниях в этот процесс вкладывают больше, чем он может дать. Иногда ошибочно считая что только детальное и дотошное ревью помогает обеспечить наивысшее качество проекта. А еще хуже когда внедряют метрику "сколько ты сделал комментариев реквестам". Так некоторые эксперты искусственно создают свою значимость и отказываются от движения вперед.

Для меня код ревью теряет ценность и становится каким-то около формально-бюрократичным процессом во многих компаниях. Я выделяю несколько причин:
- слишком большой поток реквестов и ревьюеров размывает ответственность и не дает нормально вчитываться
- сложные и большие реквесты даже если ревьюится, то уже поздно на что-то глобально влиять. Код написан. Ты не можешь развернуть разраба и приходится идти на компромиссы. Тут лучше справляется арх ревью, а не код ревью
- в крутых командах высокое доверие. Если тебе нужно выделять час времени и писать 30-40 комментов своему коллеги, то проблема сидит глубже.
- в больших компаниях и командах кодревью почти условное из-за огромного кол-ва велосипедов, BDUI, кроссплатформ и тп. У тебя не хватает экспертов кто также хорошо разбирается в том, в чем разбираешься ты

Вот и автор приводит данные: сравнение команд, где код-ревью обязательны, и тех, где их нет или они используются по желанию.
- Команды без обязательных ревью работают быстрее, но выпускают больше багов
- Команды с обязательными ревью имеют меньше багов, но могут быть медленнее

Вывод автора: обязательные ревью — не универсальное решение. Он предлагает: пусть ревью будут выборочными, качественными и быстрыми.

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

Servant Leadership

Не все идеи agile и scrum я поддерживаю. Но некоторые очень нравятся. Например идея о сервант-лидерстве. Есть в ней что-то самурайское.

Сервант-лидерство = “служить, чтобы вести”: лидер ставит успех людей выше личных заслуг, действует с позиции скромности и не "забирает" себе победы команды. Ключевые принципы: доверие, эмпатия, сотрудничество и этичное использование влияния; лидер «ведёт из-за спины», убирая препятствия и помогая самоорганизации.

Это стиль для лидеров в команде — фокус на создании условий, в которых команда сама принимает решения и растёт.

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