Architecture Decision Records

Мы уже выяснили, что архитектуры — это не про выбор паттерна между VIPER/TCA/MVP. Писали это посте "Вы переоцениваете UI-архитектуры" и "О, нет! Ты выбрал неправильную UI архитектуру!". И нет, выбор архитектуры это тоже не про шаблонное рисование схем "System Design Interview: как сделан ютуб".

Выбор архитектуры — это оценка ресурсов, сроков. Где выбирая архитектуру ты должен задумываться об ее росте и сопротивлению деградации. Так тебе и команде проще жить.

Теперь перейдем из абстрактных советов к практике. Один из важных инструментов, которые помогают разрабам — это ADR.

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

В больших и сложных проектах, где внедрение или изменение технологий может идти годами. Может произойти такой момент, где все потеряют смысл и вектор происходящего. Зачем мы это делаем? Почему такое было сделано? Куда мы идем?

В этот момент помогают такие инструменты как TDR или ADR. На моей работе даже сейчас одна из сложных задач — это понять и зафиксировать вектор, а также не размыть и потерять все контексты.

Если у вас такие же проблемы, то вот отличные подборки публичных гайдов:

🌟 adr-tools
🌟 Amazon
🌟 GitHub
🌟 RedHat

ADR, System Design и глобальные рефакторинги

Кстати, отличная новость для тех, кто не знает чем заняться в субботу.

❣️ Тут в Яндексе устраиваем фестиваль практики и технобатлов для мобильных разрабов.

Если хотите увидеться, то я выступаю с нашим руководителем мобилки. Это не совсем доклад, а peerlab. Здесь ценится обмен живым опытом и общение.

На нем мы:
🌟поделимся опытом с каким вызовами сталкиваемся в разработке сложных продуктов большой экосистемы
🌟обсудим про mobile system design
🌟какие сложные задачи мы делаем в команде
🌟как планируются и реализуются сложные рефакторинги
🌟что такое ADR и как у нас происходит арх.ревью

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

А также многое другое. На этом ивенте мы будем много общаться и дискутировать.

📍Приходите поддержать)

📺 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