🧬 Сборник 100 задач на управлению памятью: Задачи с 30 по 40

Вы не забыли, что я делаю самый большой сборник реальных задач на управление памятью?

Стоит амбициозная цель сделать 100 задач. После решения которых не будет никаких проблем в реальной практике.

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

Поэтому цель сборника набить руку.

Предыдущие части:
🔘Подборка задач и вопросов: Сopy-on-Write
🔘100 вопросов для подготовки к собеседованию по управлению памятью
🔘100 задач по управлению памятью

🧬 Получить материалы вы можете 💰 тут или ⭐️ тут

SwiftUI: Advanced View Trees vs Render Trees

Начал новый большой цикл статей и материалов по SwiftUI. В этом блоке мы затронем фундаментальные вещи о важных концепциях:
🟣View Trees vs Render Trees
🟣Процесс рендеринга
🟣Indentity
🟣Лучшие практики
🟣Решение задач на практике

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

🧬 Получить материалы вы можете 💰 тут или ⭐️ тут

Performance analysis of SwiftUI and UIKit

кек. Изучаю перфоманс двух фреймворков и нашел чью-то магистерскую диссертацию.

В ней автор делает анализ перфоманса по двум ключевым метрикам:
🟣время работы CPU;
🟣использование памяти для различных UI-компонентов.

Ключевые результаты:
🔘UIKit в целом показал примерно на 25% лучшую производительность, чем SwiftUI
🔘SwiftUI стабильно потребляет больше памяти, чем UIKit во всех сценариях
🔘Наибольшая разница в использовании памяти наблюдалась в сценариях с кнопками и коллекциями

В целом, результаты не сильно удивляют. Так как SwiftUI все же зарекомендовал себя на рынке как фреймворк для быстрых прототипов и простых приложений.

The Composable Architecture — худшее, с чем я работал

В прошлом посте мы обсуждали тему декомпозиции и косвенно затронули тему архитектуры. Сейчас мы косвенно поговорим почему выбор паттернов и шаблонов, слепое натягивание SOLID'ов и использование чужих шаблонов чаще вредит, чем помогает.

При изучении SwiftUI нельзя не затронуть популярную архитектуру TCA. За все существование канала я почти о ней не писал и это не просто так. И сейчас объясню почему.

За практику работы с VIPER, когда его пихали в любой проект, я понял, что архитектурные паттерны UI слоя тоже должны выбираться с умом. У этого процесса должен быть этап обсуждений с командой и сбор требований. Груммить и челенджить их нужно до написания кода. Это здоровый и осознанный подход.

Но такого в 90% нет. Обычно какой-нибудь новоиспеченный лид с опытом 2 года насмотрится докладов с конференций или начитается статей. И вдруг заставит всех через диктатуру перейти на любимую им архитектуру. Я считаю этот подход самым худшим и наименее эффективным.

Вторая причина почему TCA мной нелюбим — это его попытка угодить всем и сделать стандартизированное решение. Люди пытаются сделать жестко ограниченный шаблон или фреймворк для 90% задач, но так не получается и ограничения приводят лишь к проблемам. Даже в нашем чате есть пару историй, как адепты TCA в итоге отказываются от него в проектах.

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

Вот и автор статьи делится критическим взглядом на опыт использования:
🟣Крутая кривая обучения: многие говорят, что большинство проблем с TCA — это skill issue и зависит от кривизны рук, но я так не считаю. И если технология требует много времени на обучение — это не очень и хорошая технология. Можно и молотком выполнять 90% задач.

🟣Сложность структуры: Feature, State, Action и Reducer, приводит к усложнению кода и увеличению его объема.

🟣 Проблемы с производительностью: обсервинг состояний в TCA приводит к избыточным перерисовкам, что негативно сказывается на производительности.

🟣Навигация и композиция: Автор критикует подход TCA к управлению навигацией и объединению функций, указывая на излишнюю сложность и нарушение принципов SOLID, особенно принципа единственной ответственности.

🟣Управление зависимостями: Использование собственной системы управления зависимостями в TCA рассматривается как избыточное и усложняющее код без явных преимуществ перед стандартными методами.

Топ советов для себя в начале пути

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

🟣Нет никаких гайдов.
Когда ты новичок ты думаешь, что твоя работа — это только писать код. Но чем дольше ты в индустрии, тем лучше понимаешь, что код — это только 1/10 эффективного результата.

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

🟣Изучай всё. Наша индустрия развивается быстрее всех. Она создает целые виртуальные вселенные и только находясь внутри нее ты можешь ее чувствовать. Но иногда нужно выходить за границы и смотреть на нее со стороны.

Изучай базу, алгосы, архитектуры. Они отличный фитнес для улучшения кодерских навыков. Вдохновитель на новые идеи. Закрепление старых.

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

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

Особенно актуален этот навык с развитием ИИ, где все мы перестанем быть кодерами и будем микро-предпринимателями.

🟣Будь частью команды.
Программирование стало командным видом спорта. Эпоха соло кодеров ушла. Большинство проблем, которые мы решаем — это договоренности, сбор требований и понимание потребностей. Ты выигрываешь не когда пишешь самый крутой код, а когда команда выпускает рабочий продукт.

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

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

В одном из последних ИПР на работе мы с моим руководителем придерживались концепции "80/15/5". Где 80% — это практика на работе, 15% это дополнительное образование и 5% это книги и другие источники образования. Многие лишь повторяют что практика нужна, но их слова или контент — это репосты чужих статей или копирование других идей. А их авторских мыслей или постов с уникальной экспертизой нет. Они лишь повторяют что важна практика, но каждое их действие — это очередная копия.

Мне не хочется идти по этому пути.