📺 Mobile System Design: Принцип Separation of Concerns

Вам больше не нужны фреймворки и шаблонные архитектуры.

Есть более фундаментальные и важные принципы, которые лежат глубже, чем SOLID. Они настолько базовые и естественные, что часто не проговариваются явно. Они становятся чем-то вроде "инстинктов" программиста. Настолько встроены в мышление, что воспринимаются как само собой разумеющееся.

К таким относятся KISS, DRY, YAGNI. А SOLID — это уже надстройка, а в основе лежат вот эти глубинные принципы, которые пронизывают всю инженерию. По сути, тру инженер не просто берет готовые фреймворки и надстройки, но и легко может оценить их с позиции фундаментальных принципов, которые являются атомами любой идеи или технологии.

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

Удивлен, что мало кто говорит про самый полезный принцип, который вызывает больше всех споров и стал отцом избыточных и фригидных фреймворков а-ля TCA, — Separation of Concerns.

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

Separation of Concerns отлично заходит с большими масштабами. Где четкие шаблоны не работают. Например, с модуляризацией проекта.

Пример:
У нас есть огромный монолит. Когда было 2-3 разраба все всех устраивало. Не было проблем с пониманием кто за что отвечает. Как только кол-во разрабов сильно выросло, то с масштабами и быстрым ростом кодовой базы, появилось много новых проблем с которыми прошлая инфраструктура не справляется.

Симптомы переросшего монолита:
- Смешение зон ответственности
- Снежный ком зависимостей
- Медленные сборки и "мертвые" ветки
- Неясная ответственность команд

Многие решают такую проблему натягивая на проект общую архитектуру а-ля VIPER/TCA. Но это работает исключительно в слабой инженерной культуре, где большинство джунов, готовых следовать правилам по инструкции.

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

Так зачем нужен Separation of Concerns?
Separation of Concerns — это принцип, который помогает системам расти без хаоса и жестких ограничений шаблонных архитектур, которые чаще ломают большие проекты и не создают культуру доверия внутри проекта. Правильное понимание и ощущение принципа помогает не скатываться в диктатуру и шаблонность, которая будет вставлять палки в колеса своими ограничениями.

Полезные ссылки:
- Separation of Concerns in Software Design
- Separation of Concerns (SoC)

🎒 Обновление базы и Цикл статей: Основы промт-инженеринга для iOS разработчиков

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

Ну и самому подтянуться, чтобы не нести дичи 😂 Промт-инженеринг, из zero/one/few-shot промтинга, вырастает в сложную науку, которую нужно изучать и понимать.

Опросив аудиторию получил такие цифры:
🌟Почти 63% используют аи в работе
🌟43% имеют подписки на 2-3 агентов под разные задачи
🌟39% уже не могут без использования АИ-агентов в работе!
🌟25% уже заменили гугл, курсы, чужие материалы для обучения (!)
🌟Интерес к материалу по аи растет на 12% к каждому месяцу.
🌟уже в 35% компаниях разрешено использовать Cursor и аналоги над работой в продакшене. А где-то созданы отдельные направления.
🌟появляется новый тип собесов - вайбкодинг секция

Мы поняли, что рынок требует навыка работы с ИИ, а большинство разработчиков используют его хаотично и неэффективно. Конечно, есть градус маркетинга и хайпа в этой теме, а также слепая критика скептиков с бесполезными советами в стиле "развивайтесь" aka "не забывайте дышать". В этом мусоре важно отделить плевелы от зерен и сформировать конкретный план, а не абстрактные лозунги. Если ты стоишь на месте в параличе сомнений — ты умер.

Сопротивляться бесполезно. Многие уже подсели на эту дофаминовую иглу. Блогеры уже делают курсы по решению задач с помощью АИ. Другие организовывают конференции. А в некоторых крупных компаниях считается, что если ты не умеешь использовать аи-асссистенты в жизни, то ты — “неэффективный”. Даже у меня в компании собираются гильдии аи-enjoyer'ов и рассказывают секреты и приемы по упрощению работы.

Короче, полный отказ от этого инструмента, и отрицание пользы, — равен самоубийству и замене.

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

Давайте вместе разбирать не только внутренее устройство этих инструментов, но и границы практического применения. Соберем лучшую базу про АИ в iOS разработке. Будем экономить часы своего времени. Научимся юзать ИИ так, чтобы не ломать прод. Соберем готовые щаблоны и промты, а не абстрактные советы "изучайте базу".

Все есть яд и лекарство. Вопрос дозировок и применения. Пока остальные критикуют и тратят время — мы учимся пользоваться любым инструментом. Получить новый материал в новом формате можно тут.

В этих статьях мы узнаем:
🔘Как настраивать LLM
🔘Как работать с "температурой" и знать когда у АИшек едет крыша
🔘Техники сэмплирования: Top_p, Greedy, Top-p и тп
🔘Техники промтинга: Zero/Few shots, Chain-of-Thought, Generated Knowledge Prompting и тп
🔘уйма гайдов и полезных статей

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

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

🧑 Vibe-coding vs Prompt-engineering

Часто ИИ-инструменты ругают те, кто не умеет кодить или уже теряет навык.

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

Основной тейк критиков "Не нужно кодить бездумно с помощью АИ". Простите за вопрос, а когда вообще нужно кодить бездумно? Разве копипаст со стэкоферфлоу или статей рандомных авторов это не то же самое?

Не важно АИ это или другой источник решений — нужно всегда включать голову. И как раз грамотный promt-enginnering сильно отличается от бездумного vibe-coding'а

Давайте определим границы:

🧍‍♀️ Vibe-coding — это когда ты даёшь задачу чатгпт и он генерирует код целиком. Андрей Карпатый дал определние:

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

Такое подход имеет место быть, но только в легком прототипировании. Значит ли это, что ИИ вред и его надо забросить? Конечно же нет.

Вайб-кодинг — это про эмоции и прототипы.

🧍‍♀️Prompt-engineering — это навык формулировать такие промты, чтобы получить точный, понятный и полезный результат. Это как дизайнер языка общения с моделью: ты тщательно прописываешь контекст, формат, стиль и требования.

Это совершенно другое использование АИшек. Ты продумываешь всю ментальную карту разработки и даешь ИИ самую скучную и рутинную работу. Наставляешь и менторишь его как джуна 🤤 При этом регулируешь его "температуру" и четко понимаешь что происходит с кодом.

Промт-инженеринг — это про контроль и надежность.

Полезные статьи:
- Vibe Coding vs Prompt Engineering -Aren’t They the Same?
- Prompt Engineering + Vibe Coding: A New Era for Software Developers

💎Созвон сообщества "AI инструменты в iOS разработке"

На очередном созвоне комьюнити мы решили собрать тему про аи-инструменты. Ребята сами выбрали.

Мы перешли из стадии отрицания в стадию принятия. Слишком сильный геймченджер в опыте разработке.

Кстати, сентябрь будет самым насыщенным месяцем на авторский контент по этой теме:

🔘Созвон сообщества с практикой и обсуждением
🔘Я позвал крутого разраба из яндекса для воркшопа
🔘А закроем мы это двухнедельным марафоном.
🔘Изучим вайбкодинг собесы

Пора апгрейдиться. И пока остальные тормозят себя сомнениями и спорами — мы идем вперед.

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

👨‍🦱 Техкультура и техноквоты

На субботнем митапе, после доклада, мне задали вопрос: "Как у вас формулируются цели, которые развивают инженеров и мотивируют команды?".

Я не готов писать про весь яндекс, а поделюсь лишь своими наблюдениями. Подумав, мне кажется, что ответ прячется в уникальной практике, которая реально качает инженерную культуру.

За 5 месяцев здесь я сделал около 50 реквестов на 800–1000 строк кода в среднем. Без тестов, моков и тп. Чистая бизнес-логика и UI. Для сравнения: в прошлых компаниях за полгода набиралось от силы 20. Здесь темп выше, задач больше, возможностей расти тоже. Но главное даже не только кол-во задач и крутых продуктов, а качество культуры. Давайте разберем из чего она состоит:

🖍 Дай разрабам сказать.

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

🖥 Дай разрабам сделать.

40% времени в спринте разраб может тратить на развитие технички. У нас они называются "техноквоты". Это не пожарные продуктовые таски. Не срочные костыли. А задачи, которые развивают тебя как инженера и делают сильнее саму команду.

Это не роскошный максимум, а базовый минимум.

☕️ Доверяй, а не надзирай.

Свобода некоторым может показаться "бардаком". Они могут сказать: "А у нас в банке не дают свободы. Нужно проходить многомесячные согласования, а чтобы внедрить Swift Councurrency или SwiftUI нужно пройти 10 кругов ада защит". Но разве это хорошо, когда внутри компании нет доверия к решениям и много лишней бюрократии? Каждый твой шаг контролируют. Это убивает культуру инноваций и экспериментов.

Чем скилловей разраб, тем больше к нему доверия. Если у тебя в компании 200 разрабов, где из них 100 джунов, которые ковыряют маленькие участки кода, то в этой среде нет развития. Это надзирательство и душилово бюрократией.

Почему всё это круто?
🔘Ты прокачиваешь не только хардскилы, но и инженерное мышление.
🔘Появляется свобода творчества: можно исследовать, экспериментировать, предлагать свои решения.
🔘Такие задачи формируют культуру, где ценится не скорость "закрыть задачу", а качество и рост команды.

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

Формируйте в команде культуру доверия, поддержки и развития и тогда у вас будет культура развития и мотивации.

How I use LLMs

Вот вам двухчасовой гайд, от первого лица всех промт-инженеров Андрея Карпатова, который пробустит ваш скилл с LLMками.

Как я уже писал, что нейросети — это тоже инструмент. Не нужно выключать голову и скармливать глупо любой контент, не помогая ей разобраться и не настраивая её.

А теперь контекста. Я не думал, что нужно писать такой пост. Но иногда натыкаюсь на разные статьи и посты со сравнениями моделей от коллег. Вот недавно один ios лид какой-то компании в линкедине написал пост, где сравнил Claude vs ChatGPT. Вывод был в стиле "чатгпт пишет код лучше" 🫣 На вопрсы "А какую модель он юзал и там и там?" или "А ты юзал Claude AI или Claude Code?" он ответить не смог и сказал "ушел разбираться" :).

Также я слышал коммент "нейросетки не умеют в шейдеры". Тут сразу куча вопросов:
- а какую модель ты юзал?
- ты писал ленивый zero-shot promt?
- Наполнил свой запрос примерами? Какими?
- Использовал техники сэмплирования?
и другие вопросы

Работать с нейронкой это как с тренером в спортзале. Если ты пришёл и сказал: "Сделай меня красивым", он тебе не поможет. Нужно конкретизировать цель, программу, подходы. И только тогда будет прогресс.

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

Полезные статьи:
- Claude Code: The AI Developer’s Secret Weapon
- Comparing Chatgpt and Claude for coding tasks
- Cursor VS Claude Code: The Winner