Claude Code: Лучшие практики для инженеров

Как уже заметили в комментариях прошлых постов — влияние яндекса меня уже облучило 🧠 Не удивительно, только за эту неделю внутри компании будет >3 внутренних образовательных воркшопов как использовать ИИ для работы.

Считаю ИИ сильным геймченджером. Наступает новая промышленная революция, где старые правила уходят в прошлое. Среди немаленького кол-ва инженеров есть заблуждение, что использовать ИИ — это что-то казуальное и простое. Но это не всегда так. Опыт всех обещаний с SwiftUI, Swift Concurrency, Swift 6, BDUI, KMP нас научил, что если где-то что-то упрощается, то где-то также что-то усложняется. Приходят новые проблемы.

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

В этой статье очередная настройка еще одного инструмента. Claude Code отлично подходит для тех, кто хочет использовать AIшки как трушный инженер — через терминал.

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

💩 Vibe-coding не оправдание говнокоду

Прежде чем обсуждать статью сразу разделим программирование на два термина:
🟣вайб-кодинг, где человек пытается путем комбинаторики подобрать наугад рабочее чужое/сгенерированное решение.
🔘intentional coding — где каждое решение принимается с ясной целью.

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

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

Теперь к статье. Автор делится мнением, что бездумное использование пилотов и сам вайб-кодинг приводит к еще большим проблемам на проекте. АИшки в разы увеличивают объемы контрибьютинга, но также приводит и к растущим проблемам. Ускоряется накопление сомнительных решений:

🌟“Vibe coding” != качественная разработка
“Vibe coding” может быть полезен для прототипов или личных проектов, но не подходит для серьёзных, долгосрочных решений.

🌟Необходимость контроля качества
Даже при использовании ИИ важно проводить ревью кода, писать тесты и следовать лучшим практикам разработки.

🌟ИИ как помощник, а не замена
ИИ-инструменты должны дополнять работу разработчика, а не заменять её полностью. Для более качественных решений ИИ является лишь помощником, а не полноценным генератором рабочих решений.

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

Архитектуры 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