Способы измерения производительности Swift-кода

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

Для этого можно попробовать:

🔘 Написание юнит-теста в проекте Xcode.
🔘 Использование Playground
🔘 Написание юнит-теста и его использование через терминал.

📖 Более детально с этими способами и выводами можно ознакомиться в этом материале.

😃 iOS Dev

Правила ответственной коммуникации

После опроса про важные софты решил делиться некоторыми интересными материалами. Сам предстоящий год буду инвестировать в них.

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

📍 Какие материалы и инструменты помогают мне лучше формулировать мысли:

🟣 Знаменитая книга "Пиши, сокращай", которая стала библией у многих людей, даже далеких от ИТ. Я уже лет 5 юзаю их сайт, который подсвечивает ошибки или дает совет как сделать текст читаемым
🟣 Ну и следом туда же "Новые правила деловой переписки" от этого же автора
🟣 Отличный курс от яндекс практикума "Навыки аргументации для руководителей". Этот курс, на мой взгляд, пойдет к специалистам любого уровня. А заголовок просто кликбейтный

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

Что ждет FAANG в 2024 году?

Найм в Meta вырос на 800% с января, в Netflix на 300%.

Сайт interviewing.io на основе своих данных, подготовил предсказания на 2024 год. Сервис отслеживает, кто в какие компании готовится, какие мок-интервью покупает и кто в конце концов получает оферы.

🟢 В 2024 году FAANG начнет нанимать больше инженеров. Сейчас только Meta и Netflix агрессивно нанимают, но в следующем году остальные компании последуют их примеру.

🟢 С января 2024 года найм мидлов и синьоров значительно вырастет.

🟢 Как минимум ближайшие 6 месяцев компенсационный пакет не изменится (зарплаты, бонусы, акции).

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

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

🟢Не смотря на благоприятный прогноз, рынок еще долго не вернется к прежнему состоянию.

Подробнее о ключевом слове final

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

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

Основные причины использовать final:
🟡Оптимизация производительности. Методы и свойства становятся статическими, что помогает сократить поиск во время выполнения
🟢Поддержка цельности. Мы запрещаем изменение свойств и методов.

Async/Await for Swift

Я тут хотел освежить память в чем же плох GCD и зачем нам нужна новая система многопоточности.

В итоге, не нашел ничего полезного этого материала. Автор, кстати, был одним из тех, кто описывал пропосал по Structured Concurrency.

📌 Какие же главные минусы у GCD?

⏺ Pyramid of doom — вложенность кода с колбэками затрудняет чтение и дебаггинг
⏺ Проблема обработки ошибок.
⏺ Неэффективное использование ресурсов из-за ограничений тредов
⏺ Легко допустить ошибки с возвратом колбэков

Как саботировать работу в ит-компании?

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

ЦРУ во время второй мировой войны выпустило книгу «Simple Sabotage». В ней изложены различные способы, с помощью которых злоумышленники могут подорвать производительность компании.

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

Некоторые советы применимы к нашей области:

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

🟣Много говорите и как можно дольше. Рассказывайте личные истории и анекдоты.

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

🟣Как можно чаще поднимайте проблемы, которые не относятся к делу. Требуйте точных формулировок, соблюдения процессов и протоколов.

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

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

🟣Поднимайте вопрос о правомерности. Может ли какая-то группа людей принимать определенные действия или нет, не противоречит ли это юрисдикции департамента и политике компании.

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

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

Welcome. Небольшой намек куда ушел 🤣

Моя любимая задача с собесов по программированию

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

Алгоритмическая секция уже давно настолько упрощена, где просят только написать очень простой код. От алгоритмов и математических доказательств уже ничего не осталось. Ее уже даже перестали называть алгоритмами, а изменили на общее название «программирование». Но хейт не удивителен. Для зубрителей теории писать код — криптонит.

Статья за авторством Carlos Arguelles, бывший Bar Raiser в Амазон. За свою карьеру провел больше 1000 собеседований.

Carlos поделился своей любимой задачей по програмированию, которую уже задавал порядка 500 раз и которая, по его мнению, на 95% совпадает с итоговым решением.

🟣Для многих гораздо важнее сама беседа, чем код, который человек пишет человек. 

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

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

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

🟣Более грамотные специалисты догадываются, что скорость поиска O(1), необходимую для превращения O(n²) в O(n), может обеспечить словарь (Map). Лучшие же кандидаты предусмотрительно отмечают недостаток такого подхода, заключающийся в использовании O(n) памяти. Здесь повышение скорости достигается за счёт увеличенного потребления памяти.

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

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