Архитектуры SwiftUI: MVP vs MVVM

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

Писать про View, HStack, VStack и тп — скучно. Это легко найти в любом туторе, гпт или чатах для новичков. Нужно делиться тем, что стоит за изучением фреймворка и либ — опытом. Здесь я хочу делать акценты на важных вещах для коммерческого разработчика и опыте.

Когда говорят “архитектура” в мобильных приложениях, чаще всего говорят о паттернах, которые помогают организовать логику в UI. Так как именно с ним мы и работаем в 90% задач. Например: MVC, MVP, MVVM и тп.

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

Мы уже прошлись с критикой по TCA. Но почему столько споров вокруг MVVM?

MVVM — один из самых популярных паттернов в SwiftUI. Но есть громкое мнение: "Stop using MVVM with SwiftUI". Потому что:
🟣SwiftUI сам по себе уже привносит много реактивности.
🟣А MVVM, если использовать неправильно, может только усложнить код.

В комментах к прошлому посту даже обвиняли автора в пренебрежении SOLID, DI, CI/CD и других смертных грехах. Поэтому, нужно быть осторожным выссказывая свое мнение, что что-то не нужно.

Что же делать, если у каждой архитектуры тысячи критиков? Слушать самым подходящих нам и основываться на своем опыте 😂

Как же без богов архитектуры из The Essential Developer. Мы уже говорили про них тут, если вкратце ребята работают в фаангах и у них есть самый дорогой курс в iOS за 2500$ про систем дизайн. Когда-нибудь я накоплю бабки и разберу его для подписчиков, а пока делюсь закрытым видосом из их базы.

Скоро ждите отдельную статью в ноушене с разборами архитектур в SwiftUI.

Ну че, неделю я ежедневно кодил фичи и не редко пользовался Cursor.

Давайте поговорим про vibe coding. Где мне было кайфово, а где минус вайб.

За это время на нативке я закодил больше, чем бы за месяц в Авито 🙂 при всей моей любови, но мне там этого не хватало. Я почти все задачи писал на BDUI или бэк на Go, а в Яндексе чистый Swift. Соскучился по нему. Иногда кодинг меня засасывал до двух ночи. Авито отлично подходит качать софты, но с хардами надо чтоб повезло. Инженерно же сложные задачи для меня критически важные, тк в какой-то степени я стал заложником своего блога и историй у костра про технический контент.

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

🟣Начнем с первого вайба: вынесения констант.

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

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

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

⭐️ Оценка: твердые 4 вайба из 5.

Решил сделать вайбовые ролики про вайбовые трюки. Уходит на них немного времени, но прикольно.

Конечно, пилоты имеют также ряд дополнительных плюсов и более критичных минусов. О них поговорим в след постах.

Вкратце, когда одно чувство перестает работать, то все остальные обостряются.

Новый раздел в ноушене: AI & LLM для инженеров в мобильной разработки

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

В этом разделе будут пополняться и собираться:
🟣Как и зачем использовать LLM в работе
🟣разбор популярных и не очень пилотов
🟣советы и трюки (рефакторинг, упрощение кода, замена констант и тп)
🟣Минусы вайбкодинга и как можно запороть проект без осознанного использования

А также многое другое. Это огромная тема, которая еще наберет свой пик популярности. Она также требует скиллов и внимательности.

🧬 Получить доступ к разделу и другой контент можно 💰 тут или ⭐️ тут

How to measure productivity?

Очень советую эту статью.

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

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

Концепция outcome/output набирает популярность. Колличественные метрики заменяются качественными. Многие перестали считать коммиты, задачи, часы, сторипоинты и начали оценивать конечный результат.

🌟Output — это всё, что физически создаётся в процессе разработки: код, тесты, документация и т.д. Это результат работы команды, но сам по себе он не гарантирует ценности для пользователя.

🌟Outcome — это то, что происходит после того, как Output попадает к пользователю: изменения в его поведении, рост удовлетворённости, увеличение продаж и т.д. Outcome отражает реальную ценность продукта.

Пример: Если вы добавили новую функцию на сайт (Output), но пользователи ей не пользуются, то Outcome равен нулю.

В статье отлично выражено фундаментальное правило:

Продуктивность в разработке — это не количество строк кода, а ценность, которую получает пользователь. Важно стремиться к максимальному Outcome при минимальном Output

🌟 Большая подборка задач на SwiftUI

Месяц заканчивается и впереди майские праздники и отпуска. А я не успел отдать некоторые долги. Поэтому догоняю упущенное.

Подготовил большую подборку важных задач для закрепления теории SwiftUI. Это поможет лучше набить руку и понять базовые особенности фреймворка. Большинство из задач встречаются на реальных собеседованиях:
🌟Решение задач на утечки памяти
🌟Вопросы и задачи по навигации
🌟Вопросы и задачи по перфомансу (оптимизация LazyStack, и тп)
🌟А также практические советы и рецепты по верстке разных элементов (анимации, фильтрация элементов, drag&drop и тп)

Еще больше материала про SwiftUI:
🌟Воркшоп SwiftUI: Оптимизация и перфоманс коллекций часть 1
🌟Большая статья SwiftIU: State, Binding, Observable и частые ошибки
🌟SwiftUI: Подборка лучших задач для изучения часть 1

🧬 Получить это и весь другой контент по щедрой скидке 💰 тут. Проведи майские с пользой

Также ищу желающих провести/пройти мок-собес по SwiftUI

🌟 SwiftUI: AttributeGraph

Опрос выше показал, что аудитории менее интересны темы про основу и базу, а больше кишки и оптимизации.

Тогда перейдем в поднаготную SwiftUI. На собесах в СНГ рынке есть такая особенность, что у нас особо никто не любит спрашивать базу, а сразу лезут в кишки. Для меня это спорный подход, но все же быть готовым к нему нужно. Поговорим про AttributeGraph.

AttributeGraph — это закрытый фреймворк SwiftUI. Он отслеживает зависимости между данными и вьюхами.

Когда вы используете свойства, такие как @State, @Binding или @ObservedObject, SwiftUI создает граф зависимостей, чтобы понимать, какие части интерфейса нужно обновить при изменении данных. Вместо того чтобы пересчитывать весь UI, SwiftUI благодаря AttributeGraph обновляет только те части, которые действительно изменились. Это делает апки более производительными.

Понимание работы AttributeGraph помогает:
🌟Избегать лишних обновлений интерфейса.
🌟Оптимизировать данные и вьюхи для лучшей производительности.

Позже сделаю более детайльный пост с инфографикой.

Доп.статьи:
🌟Untangling the AttributeGraph
🌟Making Friends with AttributeGraph
🌟видео objc: Attribute Graph (Part 1)
🌟Demystifying SwiftUI: Attributed Graph

Теперь можете брать задачу на собесы для SwiftUI - написать свою реализацию AttributeGraph 😂

🛍Приглашаем на большой митап Яндекса по мобильной разработке!

На Я.Субботниках технические специалисты Яндекса рассказывают об устройстве сервисов, над которыми они работают. В этот раз собираемся в двух городах — Москва и Санкт-Петербург!

Что ждёт участников:
🟠5 докладов про iOS и Android;
🟠PeerLab: разбор кейсов из реальной практики с экспертами;
🟠Afterparty и нетворкинг

Среди тем докладов этого года: секреты адаптации мобильного приложения под ТВ, стратегии ускорения старта и observability-система для BDUI. Полное расписание ищите на сайте.

➡️ Регистрируйтесь и приходите слушать доклады, задавать вопросы и обсуждать кейсы