🤘В прошлый четверг выступил на Android-митапе в Звуке, где я являюсь лидом Android-платформы.

Рассказал о том какой путь мы прошли от обычной Android-команды из пары человек в отдел мобильной разработки из 25 Android-разработчиков, работающих в 10 продуктовых и платформенной команде. Особое внимание уделил рефакторингу и работе с техдолгом, а также показал пример Roadmap'a платформенной команды.

Вообще Android-митап вышел очень структурным, сначала я рассказал о платформе, а потом ребята из платформы поделились своим опытом: как разрабатывали дизайн-систему в Звуке и как работает музыкальный плеер.

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

​​👨‍💻 Зачем ходить на конференции? Выводы и ссылка на доклады

На прошлой недели посетил в Сколково крупнейшую конференцию для тим и техлидов TeamLead Conf 2023. Напомню, что являюсь тимлидом платформенной команды в стриминговом сервисе Звук, где мы занимаемся архитектурой и оптимизациями проекта.

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

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

📚Ну и в качестве бонуса плейлист на все доклады прошлой конференции, будет полезно не только тимлидам, но и тем, кто хочет ими стать или улучшить софт-скилы.

📚 Реальные задачи на System Design собеседовании для мобильного разработчика

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

Итак, какого типа задачи ожидать на System Design интервью для мобильного разработчика? Это реальные задачи которые я видел:

📌 Спроектировать приложение прогноз погоды.
📌 Спроектировать банковское приложение для отслеживания котировок акций.
📌 Спроектировать приложение для отслеживания заказа.
📌 Спроектировать приложение редактор картинок

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

О чем еще неплохо порассуждать и показать что вы знаете о чем говорите:

📌 Реляционные БД vs No-SQL решения
📌 Server-Driven UI
📌 Способы тестирования и плюсы минусы тех или иных подходов
📌 MVP vs MVVM vs MVI.

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

Ну и напоследок, самое главное что от вас ожидают на System Design интервью - это способность задать уточняющие вопросы, предложить идеи. Не начинайте рисовать диаграммы пока не спросите 5-10 вопросов. Если молча начать проектировать архитектуру - это красный флаг.

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

- Набор примеров задач для System Design Interview
- System Design. Подготовка к сложному интервью. Автор:Алекс Сюй
- System Design Template
- System Design CheatSheet

⚙️ Взламываем System Design интервью для мобильного разработчика.

Как и обещал, написал детальную статью по System Design интервью для мобильных разработчиков. Тут кратко расскажу про этапы и рекомендации, а на хабре более подробно с примерами и диаграммами. https://habr.com/ru/articles/781404/

В зависимости от процессов найма в компании на System Design у вас будет скорее всего около 1 часа. Это супер мало, поэтому четко планируйте время и старайтесь придерживаться следующего тайминга:

1️⃣ Понять условие задачи и собрать требования (5-10 минут). На этом этапе важно собрать как можно больше требований и досконально понять проблему какую вам нужно решить. Иногда вам могут дать уже какую-то заготовку, например скриншот какого-то приложения и спросить как спроектировать функционал показанный на этом скриншоте. На данном этапе приветствуется задавать вопросы. В первую очередь запишите что именно будут делать пользователи, опишите возможные сценарии использования.

2️⃣ Построение общей архитектуры верхнего уровня. (10-15 минут).

На этом этапе вы уже можете брать виртуальный маркер и начать рисовать верхнеуровневую диаграмму. Вам необходимо нарисовать блоки с ключевыми компонентами системы. Если говорить про Android-разработку, то нужно упомянуть принципы Clean Architecture и разделение по слоям. Комментируйте вслух почему вы решили использовать тот или иной компонент, какая у него будет ответственность. Например: DataSource будет отвечать за кэширование данных, потому что мы будем использовать offline-first подход.

3️⃣ Детальное описание каждого компонента вашей архитектуры и выбор решения. (20 минут).

На данном шаге вы согласовали требования и спроектировали примерную архитектуру. Теперь необходимо углубиться в каждый из компонентов и описать как бы вы реализовывали тот или иной компонент. Имея список компонентов (в реальном интервью он у вас на схеме перед глазами) вам необходимо пройтись по каждому и рассказать плюсы минусы альтернативных решений и почему вы выбрали именно это. Например реализация кэширования через Room vs Realm, использование сокетов или Rest API и т.д.

4️⃣ Подведение итогов и ответы на вопросы. (10 минут).

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

Рекомендации

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

⏰ Следите за временем. Интервьюер может вас отвлекать - ваша задача максимально полно представить решение за короткий срок. Заранее ознакомьтесь со средой в которой будете рисовать. Это может быть Draw.io, Excalidraw.

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

Друзья, поздравляю с Новым 2024 Годом! Желаю вам исполнения желаний и покорения новых высот!

​​🚅 Простое объяснение работы Sequence API в Kotlin.

Представляю вам отличное объяснение работы Sequence в Kotlin. Материал настолько мне понравился, что я решил перевести статью и картинки и поделиться ее с русскоязычным комьюнити android-разработчиков. Буквально сегодня на одном из собеседований я задал вопрос про отличия и кандидат не смог ответить. Если вы смутно представляете в чем разница работы Sequence vs Collection API, то не поленитесь потратить 5 минут и разобраться. Тем более с картинками все проще чем кажется. Прочитать статью

⚙️Используем join в SQLite-запросах Room для android

В одной из версий Room была добавлена удобная фича, которая упрощают написание методов DAO и позволяет возвращать данные запросов в формате Map<key,value>. В этом посте мы вспомним про форматы JOIN в SQLite и напишем простой пример, демонстрирующий новую фичу в Room. Если совсем кратко, то теперь необязательно создавать дополнительный класс-холдер для получения результата. Такой результат мы можем получить, используя inner join.

https://habr.com/ru/articles/570400/

📹 Анонс моего YouTube-канала о мобильной разработке AndroidHeroes

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

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

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

📹 Как сохранить список объектов в ORM Room?

В моем текущем проекте у нас огромная БД с большим количеством разных таблиц и связей между ними. Ну оно и понятно: офлайн-режим для музыкального плеера является одним из важнейших требований. Ну и чтобы человек мог придти на проект и сразу не испугался работы с БД на собеседованиях есть отдельная секция по такого рода вопросам. И порой разработчики не понимают как работать с базой, как настроить связи и вообще предлагают все сохранять в виде json-строки. Поэтому записал видео для YouTube на тему построения связей в Room, и обновил проект на GitHub по теме relations.

https://youtu.be/CzgdEw2MuUw

📚 Диаграмма по System Design для мобильного разработчика

В последнее время даже в РФ в БигТехе, часто вместо однообразных вопросов, типа перечислите все методы класса object, добавляют секцию по System Design. Как его пройти и на чем нужно сконцентрироваться именно мобильному разработчку я писал в блоге

А в этом посте хотел поделиться классной диаграммой, наглядно описывающей каждый шаг.

Наглядные примеры работы Kotlin Flow операторов

Кто работал с RxJava, возможно, помнит интерактивные Marble-диаграммы, для более наглядного понимания работы операторов.
Было бы круто что-то похожее увидеть и для Kotlin Flow для наглядности работы.

Нашел классную статью с крутыми анимациями с пиксельной графикой, которые автор создал для объяснения работы популярных операторов в Kotlin Flow. Ощущается, как будто играешь в какую-то игру на Nintendo.

​​⚙️5 инструментов для мониторинга Android-приложений в проде

Если бы программисты были врачами, им бы говорили «У меня болит нога», а они отвечали «Ну не знаю, у меня такая же нога, а ничего не болит»

Разработать приложение это всего лишь половина дела. Вторая часть это релиз и последующая поддержка. И тут многие разработчики наивно полагают, что если с приложением будет что-то не так, то пользователи обратятся в поддержку и расскажут о своей проблеме. Так не работает. Пользователь просто удалит ваше приложение и уйдет к конкурентам.

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

В этом посте кратко расскажу основные инструменты которые могу пригодится.

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

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

Performance Monitoring - еще один инструмент от Firebase, позволяет увидеть проблемы в производительности. Например снижение скорости запуска приложения, проблемы рендеринга экранов, скорость сетевых запросов. Полезная штука, однако в том числе эта библиотека замедляет холодный старт приложения.

Android Vitals - является инициативой Google, нацеленной на повышение производительности и стабильности Android-устройств. Когда пользователь, разрешивший сбор данных, запускает ваше приложение, его Android-устройство регистрирует различные метрики, включая данные о стабильности приложения, времени его запуска, использовании батареи, времени рендеринга и отказах в разрешениях. Эти данные Google потом использует для продвижения приложения в Google Play, если ваше приложение постоянно где-то в 100-ых позициях, подумайте над улучшением метрик (батарея, размер приложения, кол-во ANR)

Redash и Grafana - аналитические инструменты для обработки большого массива данных и его визуализации. Если вы используете свои инструменты для отслеживания работы приложения, то вам все равно нужно как-то интерпретировать и анализировать собранную информацию. Эти инструменты вам помогут построить графики и вывести результаты.

Часть этих инструментов мы рассмотрим на занятии “Мониторинг приложения в проде и CI/CD” в рамках интенсива

Всем привет! 👋

Давайте знакомиться! 😊

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

📚 Полезные материалы:

Туториалы с разработкой демо-проекта:

Программирование на RxJava 3.0 для Android
Использование MockWebServer при разработке и тестировании Android-приложений
Тестирование Android Architecture Components
WorkManager для управления фоновыми задачами
Распознавание образов на базе Android ML Kit и CameraX
Разработка приложения Фитнес-календарь на базе Alarm Manager
Остальные туториалы тут

📝 Статьи:

Отличия Sequence API vs Collection
Как подготовиться к собеседованию по System Design мобильному разработчику
Шаблонный метод на примере формирования списков в Android
Принципы построения многомодульных Android-приложений
Остальные статьи тут и на Xабре

📹 Канал на Youtube:

Недавно завёл канал на YouTube
Иногда выступаю на митапах и конференциях

🎓 Интенсивы и менторинг

🔷 Интенсив для мидлов с наставником и код-ревью
🔷 Интенсив Основы Android-разработки
🔷 Если вы ищете ментора

…………………..

ℹ️ Обо мне:

Михаил Валуйский LinkedIn

Team Lead платформенной команды в стриминговом музыкальном сервисе Звук.
10+ лет в коммерческой разработке, занимаюсь Android-разработкой, разрабатывая эффективные и масштабируемые приложения.
В 2018 году в качестве техлида разработки, выстроил архитектуру и запустил с нуля основное приложение Билайн(>10 млн. установок) Имеет самую высокую оценку в Google Play среди телекомов 4.7. Сейчас развиваю музыкальный сервис Звук
До этого работал в компании Lazada (> 100 млн. инсталлов) в штаб-квартире Alibaba (Ханчжоу, Китай) в команде поиска. Работал в Rambler&Co.

⏰ Нет дэдлайна - нет результата.

Новый год уже давно наступил, через пару дней весна, а еще через 93 дня наступит лето.

В этом году я стал чуть больше обращать внимание на планирование года, но без фанатизма, аффирмаций и прочего. Поставил цели как для профессионального развития, так и личного. И сейчас будет “лайфхак” как заставлять двигаться по чуть-чуть к вашим целям.

Наверняка у каждого были какие-то планы на этот год: выбить повышение на работе, научиться играть на гитаре, заняться спортом. Так и у меня одна из целей читать минимум 3 книги в месяц, итого около 36 книг в год. В приложении Литреса есть классная штука - читательский билет. Вы можете взять электронную книгу только на 2 недели, потом доступ к ней закончится. Я специально не покупаю полную подписку, потому что для меня это очень классный стимул успеть прочитать книгу за 2 недели.

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

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

📌 Во время Performance Review можно обсудить с тимлидом ИПР (индивидуальный план развития) в котором наметить изучение новой библиотеки, языка программирования, чтения книги по рефакторингу. Когда вы обсудите такой план с тимлидом, то назад пути уже не будет, зато появится мотивация успеть в срок.

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

📌 Вписаться в Leetcode challenge

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

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

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

​​Как расти мобильному разработчику если все задачи кажутся знакомыми и одинаковыми? Заняться производительностью и инфраструктурой!

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

В апреле буду на «Стачке» выступать в секции «TeamLead»рассказывать о нашей команде в Звуке где работаю над музыкальным стриминговым сервисом. «Стачка» — крупнейшая региональная IT-конференция России с 6 направлениями и более 200 докладов от лучших спикеров IT-индустрии.

В докладе поделюсь своим опытом и результатами, расскажу:

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

📌 Проблемы которые возникли при масштабировании команды

📌 Чем занимаются платформенные команды, примеры задач

📌 Зоны ответственности платформенных команд

📌 Как подготовить проект к связке продукты + платформа

📌 Что мы сделали в первую очередь

📌 Работа с техдолгом и roadmap платформенной команды

📌 Особенности найма и работы в платформенной команде.

Будет интересно опытным мобильным разработчикам, тимлидам, тем кто интересуется работой в больших командах. Кстати, организаторы поделились промокодом на скидку 10% stachka_friends, кому актуально, залетайте

​​Архитектура и процессы стримингового музыкального сервиса.
Выступил на конференции Стачки 2024 в Ульяновске, поделюсь тут ключевыми идеями своего доклада по теме архитектуры и работы платформы. Итак, ключевые идеи:

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

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

—Все что может быть автоматизировано, должно быть автоматизировано. У нас этим занимается платформа: начиная от смены статусов для pull-requests, заканчивая скриншот—тестами. Также мы используем ktLint, Detekt с набором кастомных правил, которые бьют по рукам, в случае несоблюдения код—стайла или принятых в команде соглашений.

—Сложно улучшить что—то, если у вас нет метрик. Метрики для платформенной команды —это как система навигации для судна. Без метрик, ваш проект утонет. Следите за crash—free, performance, скоростью загрузки данных, количеством тестов.

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