Мобильное Чтиво

Тема Android подлодки — Автоматизация разработки Если у тебя есть желание выступить на одну из этих тем, то пиши мне: 🔧 Границы автоматизации: Что стоит автоматизировать, когда остановиться? 🛠 Опыт написания собственных плагинов для IDEA 🤖 Внедряем автогенерацию тестов 📑 Автогенерация по спекам API 🕵️‍♂️ Написание кастомных detekt rules 🎨 Генерация UI из Figma ⚙️ Организация CI/CD в команде 🚀 Автоматизация релизов 🔗 Интеграция GitHub Actions в проект 🧪 Автоматизация UI-тестов 📚 Генерация документации 📊 Генерация дашбордов 🤖 Как мы с помощью AI автоматизировали разработку #podlodka #conference

⚙️ Скрытые ловушки разработки SDK и API Сегодня пост из разряда мудрость дня 🧠 Есть любопытная штука, как пользователи какого-нибудь API начинают зависеть от неожиданных деталей. Они находят "лазейки" и используют API по-особенному, даже если автор этого не планировал. Это частая проблема в разработке SDK и библиотек. Хотя я сам не разрабатывал ни одной популярной библиотеки, я часто видел, как люди изощряются, чтобы использовать API по-своему. Когда я сам пользуюсь SDK, всегда советую избегать таких путей. Но если вы по другую сторону баррикад, знайте: таких хитрецов всегда будет много. В свое время это описал Hyrum Wright, и это теперь называется Hyrym's Law ⚖️

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

По мере роста популярности SDK, пользователи начинают полагаться на все аспекты его работы, даже на те, которые вы не документировали. Это создает "неявный интерфейс", и любые изменения могут вызвать хаос. И здесь я бы перешел из мира SDK в мир многомодульной архитектуры приложений. Ведь у нас с вами тут тоже самое, только в меньших масштабах. Если разработчикам SDK приходится супер тщательно продумывать API, нам тоже не помешает этому уделять внимание. Потому что если вы сделали общий модуль и многие команды его используют, то если у нас не достаточно подробно описана документация, ожидайте появление “неявного интерфейса”! 🔥 Как с этим бороться? Я предлагаю 2 банальных, но важных пункта: 1. 📄Всегда пишите документацию в таких случаях 2. 🧪Покрывайте тестами ваше API, в поисках неявных интерфесов Сталкивались ли вы с тем, что вашим API пользуются не так, как вы задумывали? #wisdom #api #sdk

📢 Голосуй за будущую тему сезона Android Podlodka Crew 12! Мы в программном комитете составили шорт лист из потенциальных тем на будущий сезон Подлодки, который пройдет в сентябре. И мы запускаем голосование по этим темам. Что за темы: 1. 🔐 Безопасность. Тут и про защиту пользовательских данных, предотвращение утечек информации, уязвимости, авторизация и прочее. 2. 🛠 Процессы разработки. Улучшай процессы разработки даже если ты не лид команды. Здесь и про Code Review, TDD, работа с техдолгом и т.д. 3. 🔧 Инструменты андроид-разработчика. Здесь шорткаты, плагины, шаблонизаторы, Gradle-плагины и т.д. 4. 🤖 Автоматизация разработки. Что стоит автоматизировать, когда остановиться, и как сделать это правильно. Тут про авто тесты, линтеры и разные премудрости в CI/CD. Переходи по ссылке и голосуй за понравившиеся темы! Также можете прямо в комментах набросить что-то. Что кажется интересным, полезным? Что кажется скучным? #podlodka

⚙️ Помни о порядке Initializer’ов в Android В Android есть такая полезная штука, как Initializer. Это класс, который запускает свой код очень рано, до Application::onCreate. Но важно понимать, что если у вас несколько Initializer’ов, они могут начать зависеть друг от друга. Например, вам надо, чтобы система логирования была проинициализирована до блока с миграцией базы данных. 🚀 Как решить проблему? Переопределите метод dependencies(), чтобы указать, от каких Initializer’ов зависит текущий. Это задаст порядок и поможет избежать проблем. Однако иногда проще создать главный корневой Initializer, который запустит все остальные, чтобы избежать сложного дерева зависимостей, как показано на картинке. Здесь важно отметить, что все Initializer’ы будут работать в главном потоке и строго по порядку, указанному в dependencies. Но есть одна тонкость — если Initializer запускает асинхронный код. Представьте, что CInitializer зависит от AInitializer, но AInitializer запускает асинхронную корутину (например, поход в файловую систему). Она может выполниться к моменту работы CInitializer, а может и нет. Это создает риск возникновения race condition. Мораль: Помните, что все зависимые Initializer’ы работают строго по порядку. Но если запускаете что-то асинхронное, будьте внимательны и проверяйте, чтобы это не создало проблем. А вы используете Initializer в своих проектах? Делитесь опытом! #appstart #initializer #android

Переходишь на Compose? Не спеши! Мой доклад с Мобиуса про наш переезд на Compose опубликовали на YouTube: https://youtu.be/Vso0QQqh8AU?si=QpIbI2Mb69ka5rHj В докладе я рассказываю про: 1. Сложности с вложенным скроллом. 2. Compose внутри RecyclerView. 3. Долгий первый запуск. Основной фокус сделан на 3й теме. Я рассказываю, что Jetpack Compose это unbundled библиотека, которая загружается в память при первом обращении к ней. Это может сильно повлиять на ваш UX, если ваше первое взаимодействие с Compose происходит не со старта приложения, а в процессе работы. Если кратко. Если вы переезжаете на Compose, и ваш первый Compose экран это не стартовый экран, то знайте, что первый заход на Compose экран будет долгим. Возможно даже заметный на глаз. #compose #mobius

💼 Ну как прошло собеседование? Я нанят? 🤔 Еще одна тема, которую недавно обсуждал — это обратная связь на собеседованиях. Когда я пришел в Додо, я был приятно удивлен уровнем открытости в компании. Одно из её проявлений — это открытая обратная связь на собеседованиях (по крайней мере, в собеседованиях по мобильной разработке). Мне этот подход очень понравился, и я тоже стараюсь его применять, когда провожу собеседования. Единственное, что я не могу сказать сразу — это делаем ли мы тебе оффер или нет. Обычно я провожу технические секции, а после них идет софт-скилл секция, где могут быть другие результаты. Но что касается технического собеседования, я всегда стараюсь быть максимально открытым. Вот основные моменты: - 🔍 Прохожусь по всем секциям и даю фидбек, как они прошли. - 🌟 Отмечаю, что получилось хорошо. - 📈 Когда нужно дать оценку, стараюсь говорить не абстрактно “вы ответили плохо или хорошо”. Говорю про свои ожидания, например: “на сеньорную роль я ожидал в этой секции услышать то-то”. - 🚩 Если собеседование прошло тяжело и по общению, и по ответам, могу сразу сказать, что вряд ли мы будем общаться дальше. - 📚 Могу порекомендовать что-то для улучшения, например, книги. В итоге, я очень часто получаю положительную обратную связь на свою обратную связь. 😊 Не знаю, есть ли в вашей компании юридические правила, которые запрещают такое делать. Но если нет, мой вам совет — давайте фидбек, это классно! 👍 #interview #tips

🌲 Trunk-based Development: ветки или нет? 🤔 Недавно на подкасте DevZen я обсуждал Trunk-based Development и понял, что этот подход понимают по-разному. Давайте разберемся. TBD — это когда мы всей командой работаем в одной ветке. develop или main — не важно. Не каждый в своей отдельной ветке, а все в одной. Отсюда и возникает слово trunk. Но что это означает? Каждый коммит мы пушим в наш trunk? Не совсем. Хотя, можете и так попробовать, вдруг вам подойдет. 😄 Если почитать главного популяризатора этого подхода Пола Хаммата и его сайт, то там написано, что команда работает в короткоживущих ветках. Да, каждый работает в ветке, но каждая ветка живет очень недолго — 2-3 дня максимум. И это очень важное правило, которое позволяет: ✅ сохранить преимущество всех проверок кода (тесты, линтеры) ✅ сохранить код ревью. Оно становится более легким и простым, ведь в короткоживущей ветке вы не сможете понаписать очень много кода, а значит, и код ревью пройдет быстрее и легче. Про TBD можно рассказывать еще много, этот подход включает в себя несколько разных техник. Но запомните основное: TBD не означает, что веток вообще нет. TBD означает, что ветки короткоживущие! ☝️ #tbd #trunkbaseddevelopment

📚 Как слушать аудиокниги и не бросить это завтра Раньше я вообще не умел слушать аудиокниги. Пробовал несколько раз — слушал, слушал... и бросал. Внимания не хватало, контекст ускользал. И я говорю не про художественные книги, а про технические. Так что же стало моим спасением? 🦸‍♂️ Всё очень просто — делать конспект после каждой главы. Вот вам мой алгоритм: 1. 🔊 Прослушал главу — сделай конспект. 2. ⏰ Лучше всего сделать конспект не сразу, а через время, например, вечером. 3. 📖 Когда делаешь конспект, можно подглядывать в текстовую версию. Ничего страшного. У меня с этим лайфхаком контекст не теряется, внимания хватает, интерес сохраняется! Конечно, это работает конкретно для меня. Ваш опыт может быть другим. Но попробуйте, вдруг сработает! А как вы слушаете книги? Удается ли вам удерживать внимание? Делаете конспекты? 🤔 #books #lifehacks

Сходил на подкаст DevZen В прошлый понедельник я сходил на подкаст DevZen. Выпуск назвали Откалиброванный Android. Если честно, я забыл почему откалиброванный, но Android потому что гостем был я и мы обсуждали Андроид 😅 Мы отлично поболтали с ребятами, подкаст был насыщенный, много всего обсудили. Темы, которые мне больше всего запомнились, и о которых я поговорю подробнее в будущих постах в этом канале: - Как я научился слушать аудио книги. Да, раньше я не умел 🙈 - Кто как понимает Trunk-based Development 🐘 - Про крутость давать фидбек на собеседованиях 🎼 Кому интересно, то послушать подкаст можно на: - Spotify - Apple Music - Или просто на сайте Но если времени нет ⏱, то я расскажу про темы сверху в ближайшие дни в этом канале. #podcast

Сколько мобильных разработчиков надо, чтобы вкрутить лампочку разработать приложение? У нас в Додо сейчас есть 2 основых мобильных приложения: это Dodo Pizza 🍕 и Drinkit ☕️. Бренд Dodo Pizza в России известный, приложением активно пользуются миллионы пользователей, команда постоянно развивает и улучшает приложение. Как вы думаете сколько мобильных разработчиков надо, чтобы разрабатывать и развивать такое приложение❓ Если честно, я не знаю сколько надо. Но я могу сказать сколько на самом деле — приложением Dodo Pizza занимается 12-14 мобильных разработчиков на платформу (на одной платформе чуть больше, чем на другой). А над мобильным приложением Drinkit (может кто-то даже пробовал наше кофе и приложение?) — 3-4 мобильных разработчика на платформу. И тут мне очень интересно ваше мнение: - Как вам кажется, это много или мало? - Сколько в вашей компании мобильных разработчиков на проекте? #team #process