Шум в интернете: О, нет! Ты выбрал неправильную UI архитектуру!

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

Я не фанатею от сложных анимаций или Metal. Не фанат шаблонных паттернов вроде VIPER или TCA — часто они выглядят как затычки реальных дыр в навыках проектирования. Не цепляют вечные споры про "правильное" понимание SOLID или CLEAN.

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

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

Один из таких лишних шумов — это спор про "идеальные архитектуры". Мне нравится, как точно выразился Tjeerd in 't Veen:

UI architectures are like fashion. They go in and out of style, and they can bring fresh perspectives, but they aren’t as important as you might think

Кто застал взрыв инфомусора в 2018, когда из каждого утюга придумывали новую архитектуру — тот помнит что в итоге все легко забылось: RIBs, VIPER, YARCH, UDF попытки. Это все попытки найти философский камень, который закроет проблему отсутствия опыта у разработчиков в проектировании. Ограничивая их и закрывая в клетке новых проблем.

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

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

А какие у вас принципы борьбы с шумом?

Videcoding in prod

Одна из полезных лекций из серий туториалов anthropic.

Заметил забавный момент. Часто на ИИ в иос сообществе блогеров жалуются те, кто давно отошел от практики: управляют, занимаются другим, навыки атрофировались. Страх перед прогрессом мешает понимать, что происходит.

Для меня все проще: ИИ — это тоже инструмент.

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

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

(пост был исправлен чатгпт 😬)

🍗 Фичалид ака Фичадрайвер ака сеньор в 2025

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

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

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

Фича-лид (feature lead) — это разработчик, который берёт на себя ответственность за реализацию конкретной фичи (функциональности/части продукта) от начала до конца, а не просто пишет код по задаче.

Что делает фичалид:
🟣Помогает продакту проработать фичу: какие есть сценарии, цели, риски
🟣Декомпозирует фичу на задачи, договаривается с другими инженерами
🟣Лидирует разработку, следит за сроками, качеством, решает блокеры
🟣Сводит вместе все части: фронт, бэк, дизайн, аналитика
🟣Помогает или организует тестирование: сам проверяет или с QA
🟣Катит фичу в прод, следит за метриками, реагирует на баги или фидбэк

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

В чём отличие от обычного разработчика?
🔘Фичалид отвечает за весь результат целиком
🔘Смотрит на фичу как на ценность для пользователя
🔘Согласовывает, организует, ведёт за собой
🔘Организует и фасилитирует обсуждение

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

Скрин взят у моего бывшего рука из авито

Полезные ссылки:
- ожидание от сеньора в авито
- Feature Leading in Agile Teams
- A Great Developer Doesn't Always Make a Great Technical Leader

💎 Swift Concurrency: Разбор практических задач

Теория — теорией. Практика — основа.
В закрытой базе мы сделали обзор практических задач для SC:
🌟классические параллельные запросы
🌟частая задача на собесах в новой интерпритации используя SC
🌟Ограничение количества параллельных запросов
🌟И многое другое

Такие задачи помогают тренировать насмотренность и быть готовым ко многим проблемам.

Собрал в удобном формате правильно/неправильно. Кстати, чем больше погружаешься в SC, тем больше деталей замечаешь и не все так легко, как кажется.

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

Top Reading Lists

Мы то, что мы едим. Поэтому я не хочу выглядить так, будто навернул с утра мешок говна.

Последний год я активно пересматриваю свой рацион питания. Фильтрую мусор не только в еде, но и в остальном потреблении: кино, музыка, книги. Мне хочется очиститься. Вывести токсины. Стать лучше, говорить лучше, писать лучше, думать лучше.

Самое сложное пока с книгами. В нашем быстром зумерскем мире нет месту долгим занятиям. А книги — лучший тренажер для концентрации. Некоторые книги — это не легкая прогулка, а сложный тренажер, который нужно декодировать и изучать. Перечитывать 3-4 раза. Собрал полезную подборку книг, которую я когда-нибудь прочитаю хотяб на половину:

🟣https://blog.pragmaticengineer.com/my-reading-list/
🟣https://www.essentialdeveloper.com/book-suggestions
🟣https://swiftrocks.com/software-engineering-book-recommendations

📺 Мок интервью: База про СI/CD

Я считаю несправедливо непопулярной темой про CI/CD.

По опросу в канале аудитория посчитала, что это легче, чем "красить кнопки". Я посчитал это булщитом и большим заблуждением в сети. Поэтому я искал эксперта, кто может пояснить за CI/CD.

Как сказал Иван @MeGaPk:

Жизнь делится на "до СI/CD" и "после"

В этом выпуске мы поговорили про:
🟣почему зарплаты MobDevOps'ов самые большие на рынке
🟣Почему многие думают, что СI/CD это только настройка Xcode Cloud или Jenkins
🟣как внедряют АИ кодревьюеров в CI/CD флоу
🟣Самые полезные функции для работяг
🟣Стоимость настройки на стандартном проекте
🟣Fastlane и другие тулкиты
🟣Как доказать бизнесу важность CI/CD

Выпуск на следующих выходных. А я по традиции буду чаще публиковать посты всю неделю для фактуры и глубины контекстов.

Эстическое программирование. Что есть творчество?

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

В ит у нас есть много задач, о которых нужно задумываться:

🛠 Функциональность — это инженерная сторона. Здесь мы занимаеся соблюдением требований, оптимальностью, прорабатываем устойчивость к ошибкам. Нужно сделать минимальный объем работы.

💎 Но есть и художественная сторона. Это — эстетизм. Мы, как фронтенд разрабы, чаще оцениваем приложения именно этими метриками. Гармонией архитектуры. Выразительностью кода. Вниманием к деталям, которые делают продукт "приятным в руках".

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

Любая архитектура — это дизайн. Но не любой дизайн — это архитектура.

Архитектура всегда предполагает проектирование: мы выбираем модули, связи между ними, границы ответственности. Это процесс, где есть структура, правила, ограничения. А дизайн может быть чисто утилитарным. Например, мы выбрали архитектуру TCA/VIPER для мобильного приложения — это дизайн, но в нем нет особого авторского штриха.

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

Позвольте мне стать Толстым Достоевским и определить что является силой и творчеством. Так что убивает бессилие?
🟣Изящное решение сложной задачи. Минимальное, но мощное.
🟣Неочевидная, но логичная структура. Упрощает жизнь всем.
🟣Выразительность кода. Когда читаешь код и понимаешь без комментариев.
🟣Умение отрезать лишнее. Творчество не в добавлении, а в удалении ненужного.

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

You're all CTO now

Прикольный микро-пост.

Автор был разработчиком, потом CTO. Со временем он почти перестал писать код, оставив только небольшие исправления. Он сравнивает, что текущие программисты становятся такими же менеджерами АИ-агентов.

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

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