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

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

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

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

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

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

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

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

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

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

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

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

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

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

🗑 Почему наш подписчик от TCA отказался

По следам прошлого поста получили свежий отзыв от подписчика чата про выпил TCA. @ios_iss_blog решил дать очень ценный и хорошо сформулированный комментарий. Поделился своим опытом использования TCA на большом проекте. И как они от него отказались. 😬

Он обещал написать большую статью на Хабре с детальными примерами. Очень ждем.

У TCA очень много преимуществ, начиная от эргономики, observability и высоким уровнем возможности покрытия тестами

Это все достигается, если использовать главный стор, из которого скоупами ты создаешь чайлд сторы, создавая дерево сторов.

При этом, есть несколько особенностей:

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

1) Таким образом достигается observability, и в этом и есть смысл TCA

2) Нельзя приватить actions в чайлд сторе, так как это enum, поэтому любой чих в приложении, это редьюс всех сторов

3) Да, в простых приложениях редьюсеры лежат на стэке, и, мол, прогон каждого экшена - ничего страшного, из этого возникают новые проблемы:

i: Переполнение стэка (прям мужицкий краш, из-за которого есть гайды, как перекинуть стэк в кучу в TCA)

ii: По моим замерам на банковском приложений (простом технически, но много флоу и экранов), при открытии глубоко экрана по иерархии с CPU начинается беда, и каждый клик кнопки начинает «ощущаться» физически

iii: Практики начинают создавать мультисторы, когда помимо корневого, то создаешь новые, но связываешь их не через скоуп TCA, а через экшены в конкретном флоу. Это позволяет приватить (логически) экшены, потому что ты их не отправляешь сам, но тут начинает теряться весь смысл TCA

возвращаемся к особенностям:

- Сомнительная работа в рамках Swift Cuncurency:
1) нельзя редьюсер подписать под main actor, и в редьюс методе приходится писать переходы на мейн поток

2) казалось бы, а если бы всю эту жатву вынести в бэкграун поток, таким образом вся бизнес логика будет в бэкграунде (мечта любителей бигтеха?). Если коротко - то нет, редьюсеры чисто на главном потоке, если мы говорим про основное дерево редьюсеров

3) из-за этого нельзя (можно, но больно) создавать редьюсеры для сервисов, чтобы был observability и stability сервисов. Опять же можно, но с главного потока либо прочие костыли. Да и опционально создавать их тоже гемор, с особенностями

возвращаемся к особенностям:

- баги и краши TCA. Если коротко: они есть

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

- Тянешь TCA, значит тянешь 10+ либ, ребята молодцы, но уровень входа в проект растет. Плюс дока и экзамплы оставляют желать лучшего.

Наверняка еще что-то было, и, в целом, мы со всеми недостатками нашли способ работать, но вот когда начало страдать CPU, было началом конца TCA в нашем проекте

Кст выпил TCA очень прост, заменяем редьюсер на VM, редьюс метод на func, а стейт на @Published

Даже половина тестов сразу сохранили

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

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

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

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

🧑‍💻 SwiftUI: Подборка лучших задач для изучения часть 1

⏺ Уровень: Junior

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

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

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

Кстати, в базе уже есть два авторских роадмапа: общий от комьюнити и роадмап по SwiftUI от разрабов Авито

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

Подборки книг для инженеров от разраба Spotify

Пока я в небольшом отпуске перед выходом на новую работу, ищу себя чем занять. Прошел две части Ori (одна из лучших игр ever), посмотрел пару сериалов, походил в бани и зал. Даже с женой посмотрели пару выпусков "Беремена в 16". И узнал что такое мемы про italian brainrot, мой любимый это crocodilo bombardino.

Но пора потихоньку выходить из такого отпуска. Начинать разминать мозг. Вот подборка крутых книг от сеньора иосера и нашего любимого блогера:

🟣Write Great Code: Understanding The Machine (Randall Hyde)
Лучшая альтернатива Танненбауну. Понятное введение в то, как работают современные компьютеры. Книга не перегружена техническими деталями, но помогает глубже понять, что происходит “под капотом”.

🟣*OS Internals Trilogy (Jonathan Levin)
Отдельная рекомендация автора. Подробное руководство по внутреннему устройству платформ Apple. Рекомендуется опытным разработчикам, интересующимся такими темами, как загрузчики и ядра. Книги объемные и не подходят для новичков.

🟣Hacking: The Art of Exploitation
Первая часть книги посвящена C и ассемблеру, что может быть устаревшим. Однако вторая часть предлагает полезное введение в сетевую безопасность и основы реверс-инжиниринга.

💎 Большая статья SwiftIU: State, Binding, Observable и частые ошибки

Роадмапы и шпаргалки "100 вопросов на собесах в компанию N" — вымерли как формат обучения. EdTech не стоит на месте. Индусы засыпали линкедин топ 1к вопросов, их даже можно посмотреть в наших ресурсах. А чатгпт дает всю базу сразу в лоб.

Рекрутеры ищут самых любопытных. Теперь среди кандидатов выигрывает не тот, кто знает ответ. А тот, кто знает самый полный и глубокий. Чей ресерч был лучше, подходящей и практичней. А мысли сформулированней (Так он лучше промтит 😂)

Если у вас все еще остались вопросы и хочется структурировать знания по прошлым темам, то я все фиксирую в цикле статей про SwiftUI. Где все в разы детальней разбираю в ноушене. Ведь телеграм не подходит для лонгридов с кодом.

В этой статье я разобрал:
🟣как устроен под капотом State
🟣что такое Binding и как он устроен в кишках
🟣лучшие практики использования State & Observable
🟣И другое

📹 Ну а к концу следующей недели ждите тестовый мини-обучающий видос для самураев. Видео формат — будущее образования?

🧬 Получить материалы вы по подписке 💰 тут или ⭐️ тут

О важности производительности

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

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

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

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

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

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

🟣Даже крупные компании, такие как Facebook, инвестируют в оптимизацию, поскольку это позволяет сократить расходы на оборудование и улучшить пользовательский опыт.

🟣Игнорирование производительности может привести к необходимости масштабных переработок в будущем. В прошлой компании даже почти отказались от фреймворка BDUI для WEB, потому что сильно проседал перфоманс.

🟣Разработка с учётом производительности (performance-aware programming) не требует глубоких знаний ассемблера, но помогает принимать обоснованные решения при проектировании и реализации.

Пост мотивации с утра написать про дисциплину

С самого первого дня канала я пишу как фокус и как дисциплина дала мне больше, чем вдохновение и мотивация.

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

Удивлен, что чаще многого и не нужно. Просто придерживаться планов и своим словам.

Банально, мы с женой ходим в зал уже 6 месяцев регулярно. 3 раза в неделю с тренером, в 8 утра. И какого же наше было удивление как сложно найти тренера который дисциплинировано приходит в 8 утра и не переносит под глупыми отговорками. Казалось бы, режим и методичные упражнения лучше всего воспитывают самоконтроль, но нет. Три тренера подряд начали сачковать, хотя красиво стелили и клялись что они "не такие как предыдущий(ая)" и с их стороны не будет пропусков.

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

Мотивация заканчивается на третьей тренировки. На десятом посту в блоге. На пятой задаче в литкоде. На двадцатой странице в книге. На третьем спринте на работе.

Также в ит, в блогерстве и тп. Каждый поставит себе цель «попасть в компанию X» или какую-нибудь другую, но его очередная цель внезапно перебилась другой внезапной целью. Забрасывают на старте, или сдуваются. 80% громких обещаний в СМИ тихо умирают, потому что «появились более важные дела». В итоге, ни одно дело до конца не доведено. А воздух сотрясен.

В эти моменты понимаешь всю силу слов «выполняй обещания и умей доводить дело до конца». Ну и более народное «мужик познается верностью слова» 😐

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

В многозадачности дисциплина помогает от инверсии приоритетов и гонки данных.