❌ Самые частые ошибки при обучении

IT — это самая быстро развивающаяся область. Будь ты новичок или опытный разраб тебе нельзя останавливаться.

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

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

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

🔘 1. Зацикливаться на одном навыке. Частая проблема всех — это не знать когда остановиться. Что у джунов, что у сеньоров есть одна проблема. Начинающие изучают язык, но не переходят в UIKit. Поэтому они могут отсортировать массив, но не знают как сверстать кнопку со списком из этого массива.

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

🔘 2. Мало программировать. Почему-то этим страдают чаще публичные личности или новички. Когда многие путают эрудицию и реальные скиллы.

Программиста отличает навык программирования. Здесь и помогают алгоритмы, проектирование, тестирование.

Знание статей, пересказ документации, выступление с докладами, запись видео на ютубе или чтение чатов не дает навык писать код.

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

🔘 3. Ждать помощи и бездействовать. Самостоятельность — главная переменная в уравнении самообучения. Большинство разработчиков ждут, когда за них найдут информацию или сделают задачу. Это их парализует и останавливает. В этой гонке это критично.

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

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

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

🔘 5. Критиковать и не предлагать. Критика без предложений никогда не сработает. В 90% компаний фраза на собесе "эта задача никогда не будет на практике. зачем вы мне ее задаете?" будет критической и красным флагом.

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

🧬 Еще больше культуры практикующих инженеров в нашем сообществе

Как создавать большие приложения с SwiftUI: Гайд по модульной архитектуре

В чате скинули крутеший материал с разбором всех самых животрепещущих вопросов крупных компаний.

В блоге разбирается:
🔴 Модульная архитектура
🔴 Проблемы MVVM в SwiftUI
🔴 Разбор MV(x) паттернов
🔴 Навигацию
🔴Тестирование
🔴Многое другое

Когда искал серебро, а нашел золото

🧬 Архитектуры SwiftUI: MVI

В нашем пет-проекте мы почти определились с базовой архитектурой. Я уже создал в проекте первый мерджреквест с MVI архитектурой, написал статью и пролил кровь. Почему она?

UDF архитектуры главный тренд последних лет. Чем она так интересна?
🔘Декларативность и реактивность органично смотрится
🔘Однонаправленость очень удобна для понимания и работы
🔘Новенькая в мире иос
🔘Перспективная и крутая
🔘Хорошо показала себя в web и андроид

Некоторые экраны будут на VIPER, TCA. Так мы на практике тоже их попробуем.

Следующие разборы кодом будут про DI и навигацию.

🟣 Изучить вместе и накидать комменты можете здесь

💎 Подборка вопросов для собеседований

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

Сейчас в ноушене уже доступно больше 100 вопросов, 50 задач и ресурсов:

🔘Вопросы для собеседований: Многопоточка | Junior ч. 1
🔘Вопросы для собеседований: Память (Junior) ч. 1
🔘Вопросы на собеседованиях: Swift | Junior ч. 1
🔘Вопросы на собеседованиях: UIKit | Junior ч. 1
🔘Вопросы для собесов: Память | уровень Middle ч. 1
🔘Вопросы для собеседований | Диспетчеризация | ч. 1

🔘Частые алгоритмические задачи
🔘Задачи на собеседовании System Design

Цель — создать самый детализированный сборник вопросов и ответов для прохождения и проведения собесов.

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

🖥 Получить сборник можно здесь

🖱 Реализация спойлеров телеграма на UIKit

В нашем чате мы решили испытать себя и написать свой телеграм. Начали с эффекта спойлеров. Я набросал статью в ноушене как сделал его с помощью UIKit.

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

Когда-то давно я уже участвовал в конкурсе телеги и делал прикольные анимации. К ее коду уже привык. Вот решил освежить знания.

Впереди эффекты Таноса и многие другие разборы. Ставь лайк, если интересно

💎 Вступай в сообщество для таких разборов

🚘🚘 Высокая производительность для Swift приложений

Процесс оценки перфоманса довольно холливарный.

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

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

Когда-нибудь может я поделюсь внутрянкой, но а пока советы из статьи:

🟣 1. Тестировать нужно на реальных устройствах и метрики собирать оттуда.
🟣 2. Профилируйте с помощью данных и метрик.
🟣 3. Трекайте время запуска до первого экрана
🟣 4. Трекайте скорость откликов вашей апки.
🟣 5. Подбирайте разные алгоритмы для улучшения скорости
🟣 6. Используйте многопоточку
🟣 7. Нужно знать математику

💎 Больше советов и практик мы обсуждаем в нашем сообществе

🌄 DI в SwiftUI

В ноушене вышла очередная статья посвященная внедренюю зависимостей.

Попытался разобрать:
🔘 Constructor Inject
🔘 Environment Inject
🔘 Разницей EnvironmentObject и Environment

А также примеры с кодом:
🔘 Coordinator + DI
🔘 MVVM + Swinject
🔘 Наш уникальный подход MVI + DI (как зальем реквест)

🌋 Увидеть код и прочитать статью можно здесь

Делюсь первыми дизайнами онлайн-кинотеатра, нашего пет-проекта на SwiftUI. К нам присоединился дизайнер и нарисовал такую красоту.

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

🔘 Максимальные возможности SwiftUI
🔘 Сложные анимации и графику
🔘 Грамотное проектирование (system design)
🔘 Архитектурные и другие паттерны
🔘 Хранине данных
🔘 Все виды популярных архитектур: SwiftUI, TCA, VIPER, MVI
🔘 DI практики
🔘 CI/CD
🔘 Тесты и многое другое

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

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

🌄 Фундаментальная прагматика для успешных разработчиков

Многие обязательные книги для программиста — универсальные. Они не связаны с платформами: то, что работает в иос легко будет работать в бэкенде или в андроиде. Мы все разработчики программного обеспечения с одинаковой культурой, мышлением и паттернами. Языки разработки и наше SDK лишь небольшой дополнительный инструмент.

Помимо базы компьютерных наук от нас требуются базовые принципы написания и проектирования кода. Эти принципы хорошо сформулированы в довольно известной книге "Программист прагматик". Особенно обожаю идею с трассирующими пулями. Да и многие идеи из книги я вкладываю в свою жизнь.

🖥 Давайте вкратце разберем другие:

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

2. Ищите ошибки как можно быстрее. Придерживайтесь идеи fail fast. Если что-то должно сломаться и вывести ошибку, то это должно произойти как можно раньше. Потому что на начальных этапах её исправление намного дешевле.

3. Стремитесь к хорошему, а не идеальному. Никто не пишет идеальные программы. У всех ограниченный бюджет и сроки. Постоянно выходят патчи и апдейты. Тут важно правильная приоритетность и хорошее прототипирование

4. Слушайте пользователей. Не стоит предугадывыть клиентов — нужно их правильно слушать. Их удовлетворенность главный фактор успеха нашего ПО

5. Уделяйте вниманию проектированию. Прежде чем писать код нужно чщательно запроектировать. Это приводит к упрощению сопровождения кода в будущем.

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

В ноушене сделал больше разборов из книги