This media is not supported in your browser
VIEW IN TELEGRAM
Чёрная пятница для iOS Dev - в чём плюсы?
Читатели, которые поддерживают канал не только словом/комментарием или реакцией - это восхитительно, и бустит в буквальном смысле на создание новых полезных инструментов: приложения, бота, роадмапов, подборок, разборов.
Я всегда считаю, что не просто говорить, а делать всегда значит больше, чем просто строить воздушные замки. Лучше одна реализованная фича, чем невероятный проект на 5 лет, к кому никто так и не приступит.
Об этом и мой канал. О необычных вещах с простыми решениями, а ещё о том, что не всегда ИИ - это выход и спасательный круг. О критическом мышлении, сложных вопросах и многом другом.
Я пишу о том, что мне интересно. Делаю то, что мне нравится и не строю карточный домик из ложных тезисов, на которых базируется сейчас слишком многое.
А параллельно с этим по крупицам выстраиваю фундаментальную базу для изучения iOS (и делюсь личным опытом, который может пригодиться и в других направлениях).
И это только часть того, что есть уже сегодня.
Подписаться можно на бусти и в телеграме ближайшие 2 недели с приятными условиями.
Читатели, которые поддерживают канал не только словом/комментарием или реакцией - это восхитительно, и бустит в буквальном смысле на создание новых полезных инструментов: приложения, бота, роадмапов, подборок, разборов.
Я всегда считаю, что не просто говорить, а делать всегда значит больше, чем просто строить воздушные замки. Лучше одна реализованная фича, чем невероятный проект на 5 лет, к кому никто так и не приступит.
Об этом и мой канал. О необычных вещах с простыми решениями, а ещё о том, что не всегда ИИ - это выход и спасательный круг. О критическом мышлении, сложных вопросах и многом другом.
Я пишу о том, что мне интересно. Делаю то, что мне нравится и не строю карточный домик из ложных тезисов, на которых базируется сейчас слишком многое.
А параллельно с этим по крупицам выстраиваю фундаментальную базу для изучения iOS (и делюсь личным опытом, который может пригодиться и в других направлениях).
Подготовка к собеседованиям:
- Мок-собесы с публичным доступом (сейчас несколько десятков на русском и английском языках).
- Вопросы для подготовки по секциям (сотни примеров на разные темы)
- Частные узкие темы (с поиском проблем в коде).
- System Design. Мои советы и большая подборка материалов.
Алгоритмы:
- Сложность алгоритмов.
- Разбор десятков задач с контестов (в том числе и от яндекса).
- Популярные методы решения задач (с примерами).
Архитектуры:
- Все паттерны проектирования банды четырёх. Общая информация и примеры реализации на Swift.
- Архитектурные заблуждения.
- Реализация в реальных приложениях.
Необычные эффекты:
В этом разделе я делюсь анимациями, подходами к созданию и десятками примеров.
Инструментарий. Полезные советы при работе с Xcode, терминалом и симулятором.
А помимо этого - у всех подписавшихся по умолчанию есть доступ к режиму собеседований в боте и к ранним версиям приложениям iOS IQ.
И это только часть того, что есть уже сегодня.
Подписаться можно на бусти и в телеграме ближайшие 2 недели с приятными условиями.
6
Многозадачность и управление приоритетами
На моей практике не сосчитать случаев, когда появлялись задачи с высшим уровнем приоритета, которыми нужно заменить часть текущих, а при тестировании появлялись корнер-кейсы, о которых догадаться просто-напросто невозможно.
Например, управление одной учеткой в реальном времени с разных девайсов и совершение почти похожих действий могут привести порой к неожиданным результатам (предотвращение таких гонок - одна из задач в любых системах общения, будь то какой-нибудь мессенеджер, и, например, организация голосового/видео чата).
И может показаться, что есть опция захватить пачку задач сразу и выполнять их параллельно, буквально как Юлий Цезарь.
Вот только утверждение, что Цезарь делал несколько дел одновременно - все-таки миф, на самом деле речь шла о быстром переключении задач.
И хотя такой навык особенно полезен в нашей сфере, но на самом деле сумма времени, потраченного на эти несколько задач якобы параллельно, будет точно такой же и при последовательном подходе.
Поэтому рациональное желание сделать быстрее/лучше при увеличении допустимого пула задач вполне вероятно приведет к увеличению сроков.
При оценке задач с опытом приходит и то, что фича попадет в релизную сборку не только после того, как вы напишете код, но и когда её протестируют, требования по ТЗ будут уточнены, а все изменения по дизайну приняты и реализованы.
Все остальные вещи вроде наличия общей дизайн-системы, общего подхода к проверке фич и заранее заложенного времени на тестирование могут помочь, но совершенно не гарантируют, что заложенное в неделю время окажется в итоге неделей, а не месяцем.
Часто вышестоящие менеджеры могут забывать о законе Брукса, стремясь увеличить производительность команд с помощью расширения количественного состава:
«Если проект не укладывается в сроки, то добавление рабочей силы задержит его ещё больше».
На самом деле, все абсолютно логично - новых ребят, пусть и супер-толковых, всегда необходимо онбордить, естественно закладывать время на обучение от их коллег и постепенно погружать в документацию.
Да и вообще, написание кода - это лишь верхушка айсберга в продуктовой разработке.
😃 iOS Dev
На моей практике не сосчитать случаев, когда появлялись задачи с высшим уровнем приоритета, которыми нужно заменить часть текущих, а при тестировании появлялись корнер-кейсы, о которых догадаться просто-напросто невозможно.
Например, управление одной учеткой в реальном времени с разных девайсов и совершение почти похожих действий могут привести порой к неожиданным результатам (предотвращение таких гонок - одна из задач в любых системах общения, будь то какой-нибудь мессенеджер, и, например, организация голосового/видео чата).
И может показаться, что есть опция захватить пачку задач сразу и выполнять их параллельно, буквально как Юлий Цезарь.
Вот только утверждение, что Цезарь делал несколько дел одновременно - все-таки миф, на самом деле речь шла о быстром переключении задач.
И хотя такой навык особенно полезен в нашей сфере, но на самом деле сумма времени, потраченного на эти несколько задач якобы параллельно, будет точно такой же и при последовательном подходе.
Поэтому рациональное желание сделать быстрее/лучше при увеличении допустимого пула задач вполне вероятно приведет к увеличению сроков.
При оценке задач с опытом приходит и то, что фича попадет в релизную сборку не только после того, как вы напишете код, но и когда её протестируют, требования по ТЗ будут уточнены, а все изменения по дизайну приняты и реализованы.
Все остальные вещи вроде наличия общей дизайн-системы, общего подхода к проверке фич и заранее заложенного времени на тестирование могут помочь, но совершенно не гарантируют, что заложенное в неделю время окажется в итоге неделей, а не месяцем.
Часто вышестоящие менеджеры могут забывать о законе Брукса, стремясь увеличить производительность команд с помощью расширения количественного состава:
«Если проект не укладывается в сроки, то добавление рабочей силы задержит его ещё больше».
На самом деле, все абсолютно логично - новых ребят, пусть и супер-толковых, всегда необходимо онбордить, естественно закладывать время на обучение от их коллег и постепенно погружать в документацию.
Да и вообще, написание кода - это лишь верхушка айсберга в продуктовой разработке.
Please open Telegram to view this post
VIEW IN TELEGRAM
9✍9