☕️ Как я баг исправил, который не могли найти два года

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

Я всегда ищу интересные задачи: помогаю коллегам на работе; менти; беру небольшие подработки, если мне интересен проект. Так я улучшаю карму, повышаю навыки, выходя за границы привычных задач и, конечно, зарабатываю 🤡

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

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

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

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

Окей. С логами понятно, но что будем трекать?

Если зависание главного потока, то здесь на помощь приходит Watchdog. О стандартном механизме мы уже когда-то писали, но я напомню. Watchdog — это механизм, который помогает отслеживать проблему блокировки потока. Я же написал свою реализацию, чем-то похожую на эту.

Так. Мы научились понимать когда main thread завис. Теперь нам нужно как-то понимать что стало причиной его зависания.

Тут тоже все тривиально. Мы берем Stack Trace и записываем его в файл и отправляем в Firebase. Стандартный

Thread.callStackSymbols

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

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

Дополнительно сделал экран в дебаг меню, который записывает в формате "Date -> Thread.callstack" логи. Чтобы можно было сразу мне отправить лог, как только получили зависание.

После релиза, спустя десяток минут, я получил первый лог. В нем сразу была показана причина зависания. Это был мертвый код, давно ушедшего разраба. Связан он был с расширения кэша картинок для либы SDWebImage

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

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

Делитесь своими метриками, которые помогли решить редкие баги

Сегодня 01.11 у меня др

Завтра я этот пост удалю, не хотел его писать, но вдохновился постом Дурова на свой др.

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

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

Я ни разу не просил рекламу и делал только то, что нравится мне. Писал то, что думал. Старался задумываться о своих читателях. Банил хейтеров.

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

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

В нем всегда одна философия — быть полезным себе и другим.

Мы сделали первыми:
- выигрывали телеграм конкурс. Интересно кста перечитывать посты того времени
- Решали алгоритмы 365 дней
- Создавали апку "Симулятор иосника"
- Создали комьюнити
- устроили марафон по проектированию
- Сделали ютуб
- И кучу всего другого

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

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

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

Поддержать вы его можете конечно же тут 🤡

💎 БУМ! Воркшоп по собеседованию на тему Swift Concurrency

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

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

Сергей делает сложный мессенджер, где на практике использовал всю мощь Swift Concurrency.

За целый час мы узнали:
🟣Какие задачи нужно давать для оценки навыков
🟣Дает ли буст Swift Councurrency в сложных приложения?
🟣Какие знания он ждет от сеньора?
🟣Как ускорил приложение с помощью SC?
🟣Какие баги были и есть в SC?
🟣А также многое другое

Выпуск получился супер техническим и с кодом. Дополнительные ссылки и полезные ресурсы прилагаются

🧬 Получить доступ к этому видео можно тут

Об ИПР и карьерном росте

Опять же читаю книгу "the software engineer's guidebook" и дошел до советов по карьерному росту. Я как раз делал недавно новый ИПР и хочу тоже прокомментировать некоторые советы из книги, вперемешку со своими личными.

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

Иногда рост по карьере может сильно отличаться от профессионального развития, это писали при чтении книге "Growing As a Mobile Engineer". Поэтому есть много важных действий, которые необходимы к ускорению

Эти комменты могут быть полезны и вам:

🟣Иди по лестнице последовательно

Одна из моих ошибок, что смотря на следующий грейд, я думал так: "Ага, для след. грейда нужно написать статью или выступить с докладом. Слишком легко. Сделаю конференцию и там будет три доклада" или "Нужно улучшить компоненты компании. Ага, я создам новый стрим с юнит-тестами". Но этот подход не очень помогает оценить твой дифф между текущим уровнем и следующим. А также требует хорошей защиты. Для карьерного роста гораздо лучше идти последовательно к целям 1, 2, 3, 4, 5. А не пытаться прыгать 1, 3, 2, 5, 4. Лучше делать небольшие иттеративные шаги, чем прыгая вперед на два шага, а потом назад один. Это как качаться в качалке с разными весами каждый день и не иметь четкую последовательность, режим.

🟣Не игнорируй маленькие задачи

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

Маленькие задачи могут приносить большой эффект.

🟣Планируй outcome'ы на старте

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

Например, внедрение технологии BDUI помогло нам повысить метрики по качеству или выручки на 3-4%. А благодаря КМП мы ускорили разработки фичи на 30% сторипоинтов.

Иначе, без метрик или четких доказательств, все задачи будут busywork'ами.

🟣Веди логи все время

Очень многое зависит от того, как ты оформишь свой лист с перфоманс ревью. Почти как с резюме. У меня часто бывало, что когда я только начинал писать, то почти все забыл. И думал, что толком ничего не сделал, даже листа не наберу. Потом я тратил много времени собирая все свои output'ы и outcome'ы. Где в итоге, на последнем перфревью, вышло аж 15 листов (конечно, с комментами и другими артефактами)

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

А так хоть самому потом проще собирать для ревью информацию

Делитесь своими советами.

🌟 Подборка задач на Swift Concurrency

Ну и заканчиваем эту неделю разборами Swift Concurrency подборкой задач.

В них собрал все задачи, которые мы разбирали в комьюнити за последнюю неделю, а также что встречались на созвоне:
- Задача на понимание работы async/await
- Задача на группировку тасок
- Задача на отмену тасок
- И другие

💎 Бонусом сделал скидки в честь черной пятницы