Архив недели
Понедельник
Всем привет!
Меня зовут Казаков Антон. Я управляю технической и совсем немного менеджерской составляющими Android-разработки в Альфа-Банке. Вечерами читаю авторский курс по Android-разработке на платформе Otus.
О чем будем говорить на неделе я еще не решил.
Не хочу чтобы неделя была слишком душной, поэтому будем совмещать технические темы с разговорами за жизнь.
Точно поговорим о продуктивности, статическом анализе, код-ревью и саморазвитии.
Начать неделю предлагаю с разговоров о продуктивности: какие хаки вы выработали для себя, что способствует продуктивности, а что мешает.
Итак, стартуем тред про продуктивность и все что с ней связано.
Начну издалека. Самое важное что я понял за последние полтора года - нужно обязательно ходить в отпуск, лучше всего каждый квартал.
Совет звучит по-капитански, но пару-тройку лет назад я мог спокойно работать без отпуска полгода-год, и никакого падения продуктивности не замечал. Не знаю с чем это связано, возможно потому что я был моложе…
Как часто вы ходите в отпуск?
🤔
6.5% Раз в квартал🤔
39.5% Раз в полгода🤔
23.2% Раз в год🤔
30.8% Уже не помню когда ходилСитуация сильно поменялось с началом пандемии. Из-за закрытых границ улететь куда-либо стало дико сложно, и я решил отложить отпуск до лучших времен. Это была моя самая худшая идея ever.
Дорабатывал 2020 год я из последних сил, восстанавливаясь после ковида и отмечая в календарике оставшиеся рабочие дни.
Ошибка №2 заключалась в том, что я провел новогодние праздники дома, играя в WoW и дописывая плагин для импакт-анализа. Поэтому совет: ни в коем случае не проводите отпуск дома за компом, если конечно вы хотите отдохнуть.
Для меня, однозначно топ-1 способ отдохнуть и перезагрузиться - это путешествия.
А еще я всегда брал с собой ноутбук и читал чатики/мониторил графану, но в первый отпуск в 2021 году решил отказаться от этой затеи. По ощущениям мозг отдохнул намного лучше и я даже успел соскучиться по работе.
Тред (Казаков Антон)
Продуктивный денек на работе, но не очень продуктивный в Твиттере. Продолжаем.
Про отпуск вроде все, что хотел написал. В общем, не пропускайте отпуска, путешествуйте и не берите с собой ноут.
Поехали дальше. Наверное многие слышали и многие применяют в своей работе технику помидора. Расскажите про свой опыт, а я поделюсь своим.
Используете помидоры? Помогает?
🤔
16.0% Использую, очень помогает🤔
19.3% Использую, не помогает🤔
64.7% Не используюНа мой взгляд она неплохо работает, когда в день есть пара встреч, а остальное время вы пишите код. Если ежедневно вы используете Zoom больше чем вашу IDE, то от помидоров никакого толку нет.
Более рабочий, в моем случае вариант описан в этой статье thinkingthrough.substack.com/p/stop-swiss-c…. Если коротко, то добавляем в ваш рабочий календарь объемные временные блоки 2-4 часа, и это время тратим только на решение определенных задач, не переключая контекст.
Тред (Казаков Антон)
@mobileunderhood Забыть о продуктивности и думать о работе.
Это точно правильная позиция. Продуктивность ради продуктивности сомнительный путь, но иногда задумываешься почему похожие задачи ты делал быстрее, а уставал меньше. twitter.com/algridmd/statu…
@mobileunderhood Внимателен к любому сопротивлению работе, пытаюсь отыскать, что в текущем занятии его вызывает. Чаще всего это дисфункция мышления (дисфункции организации поздно искать в прокрастинации), поэтому исправляю логическую ошибку или ищу способ убрать ограничение (если оно реальное)
Звучит как начало нового треда про то, что мешает работе, а что способствует! twitter.com/MojoIvan/statu…
Начну со звукового сопровождения. Мне помогает сосредоточиться музыка, причем самая разная. То что будет звучать в наушниках зависит от того, какую задачу я решаю.
Например, когда задача сложная и я не знаю как ее решать, лучше всего помогает тишина.
Иногда еще слушаю downtempo, например soundcloud.com/tomday/popular…. Очень красивая спокойная музыка, помогает сосредоточиться
Когда задача ясна и осталось только запрогать люблю послушать Slayer.
Тред (Казаков Антон)
Вторник
Сегодня вторник и поговорим мы о статическом анализе. О конкретных инструментах, лучших практиках и процессе написания кастомных проверок. Начнем со странного опроса: какой ваш любимый инструмент для статического анализа(kotlin/android)
Ваш любимый инструмент для статического анализа
🤔
42.9% detekt🤔
20.6% ktlint🤔
23.8% android lint🤔
12.7% другой (пишите в реплаи)Андроид линт умеет гораздо больше чем анализ соурс файлов
К тому же Тор говорил в нескольких паблих толках о том что команда видит Android Lint как general solution, а не анлроид специфик инструмент
Поэтому, чисто теоретически, можно закрыть все используя андроид линт. Но на практике у наc, например, используется детект для анализа general проблем в котлин сорсах и android lint для всего остального
Кстати, кто-нибудь использовал lp.jetbrains.com/qodana/ ? Очень интересно послушать про ваш опыт.
Как справедливо заметили ниже, все эти инструмента используются для немного разных целей, для common kotlin кода - detekt(внутри него рулсет из ктлинта), для всего остального android lint
Но если рассматривать их api, процесс написания и тестирования кастомных детекторов и прочее, то мой топ это явно android lint
Во-первых, возможность поставлять вместе с вашей библиотекой джарник с рулами, которые в последствии смержаться с рулами consumer приложения и подсветят неправильное использование API библиотеки
Во-вторых, с помощью android lint можно анализировать практически все, что может лежать в android проекте. Начиная с kotlin и java сорсов, заканчивая proguard конфигами
Если говорить про стат. анализ в целом, то конечно же эта штука позволяет резко упростить и ускорить процесс код-ревью за счет автоматизации проверок, которые раньше мы делали вручную
Но если мы хотим использовать статический анализ по максимуму, то конечно же проверок из коробки не хватит. Нужны проверки специфичные для конкретного проекта
Наши системы развиваются, а значит должны развиваться инструменты стат. анализа
Сейчас мы пытаемся построить процесс непрерывного развития наших инструментов стат. анализа. Состоит он из поиска кандидатов на проверки в различных источниках, реализации проверки и подключения в проект
Самый полезный источник - это мониторинг пулл-реквестов. Если вы видите что разные люди ошибаются в одной и той же конструкции: 1) проверьте, задокументирован ли этот момент 2) напишите на него линт правило
Тред (Казаков Антон)
Среда
Новый день - новая тема. Stackoverflow собирает и публикует ежегодный Developer Survey. Мой любимый раздел в этом отчете most loved/dreaded технологии.
Давайте сегодня обсудим самые нелюбимые технологии/инструменты, которые мы использовали в Android разработке
Дисклеймер: естественно, все что я буду говорить - это только мое мнение. Возможно, оно в корне неверное по причине того, что я отстал от жизни. Начну я пожалуй с ViewModel
Лайк если помнишь как 2016-2017 году мы решали две проблемы:
в какой слой положить класс, не нарушив клин архитектуру и не обидев дядю Боба лично
где и как сохранить ViewState чтобы он переживал пересоздание Activity
Больше нас ничего не интересовало
И когда проблема сохранения уже была решена самыми разными способами начиная с Loader и заканчивая целыми библиотеками, пришел Google со своими компонентами. Спасибо и на этом
Решает она вполне понятную задачу(хоть мы ее уже и сами решили), и с этим все ок. До тех пор пока вы не решили сделать non-default конструктор для инжекта. Тогда начиналось веселье с фабриками, мультибиндингами, провайдерами и прочими извращениями
Вменяемый вид эта конструкция обрела только после изобретения Hilt’a
В общем, если бы она вышла на пару лет раньше и инжектилась без танцев с бубном было бы топ, а так meh
androidx.lifecycle.ViewModel
🤔
71.6% Loved🤔
28.4% DreadfulТоржественно включаю в мой персональный список most dreadful технологий kapt, за то как нелегко добиться его инкрементальности и как легко ее сломать.
kapt
🤔
31.9% Loved🤔
68.1% DreadfulNext one: Google Play Services. За то что они громоздкие и совершенно непрозрачные.
commonsware.com/blog/2013/05/2… статья 2013 года про сервисы и проблемы связанные с ними. Mark Murphy как в воду глядел
Ну и отдельный пунктик - куча времени и ресурсов, потраченных на адаптацию приложения под Huawei без сервисов
Google Play Services
🤔
37.7% Loved🤔
62.3% DreadedТред (Казаков Антон)
Четверг
Доброе утро! Сегодня четверг и мы продолжаем хит-парад. Сегодня поговорим о наших самых любимых технологиях и инструментах в Android разработке
Есть такие технологии, которые, кажется, нравятся почти всем(и мне в том числе). Про них говорить не интересно. Давайте обсудим спорные и недооцененные.
Мой любимый тестовый фреймворк - Spock. Он в loved за самые красивые параметризованные тесты, удобную работу с тестовыми дублерами и блоки, которые делают тесты структурированными и аккуратными.
В топ loved технологий добавляется R8. За то, что практически сразу завелся на проекте с 500+ модулей, Gson’ом и использованием Reflection API, и сломал всего пару мест в рантайме. С Proguard это было бы гораздо больнее и медленнее. Кстати кто-нибудь еще использует Proguard?
Тред (Казаков Антон)
Суббота
Всем привет и крутейших выходных! Здесь собрались люди, которые, так или иначе, связаны с разработкой мобильных приложений. Так давайте о них и поговорим.
Начнем с самых крутых приложений, которыми мы пользуемся.
Я заметил, что в повседневной жизни использую максимум 5-6 приложений. Еще с десяток намного реже, например, есть папка с отпускными приложениями. Ну и раз в год открываю Strava, когда решаю стать марафонцем.
Чаще всего я использую Telegram. Там вся личная переписка, часть рабочей и огромное количество крутых каналов. Я вообще считаю Telegram лучшим мессенджером за всю историю, и в первую очередь за счет супер быстрого и качественного приложения.
Еще я очень люблю Google Photos. Это, возможно, самое лучшее приложение, которое сделал Google. Надеюсь на gcemetery.co оно окажется не скоро.
Приложение для заметок. Тут все довольно сложно. Я пробовал кучу разных приложений: Todoist, Craft, Bear, Notion и еще много классных приложений, но ничего лучше стандартного Notes на iPhone я не нашел.
Кстати, люблю Notion. Это отличный инструмент для создания wiki-страничек. Мы даже ведем в нем часть документации, но с телефона создавать и редактировать странички лично мне неудобно.
Еще я недавно узнал что можно повесить кастомный домен на ваши Notion странички и получится симпатичный сайт. Вот мой kazakov.codes
Если вы как и я:
Любите вино
Не заканчивали школу сомелье
Стесняетесь разговаривать с кавистами в магазине
То обязательно устанавливайте Vivino!
Еще я каждый день пользуюсь банковскими приложениями. Чаще всего, конечно, Альфа Мобайлом. Хотя сейчас у всех топовых банков очень крутые и удобные приложения. Я думаю, в России лучший мобильный банкинг в мире.
Я еще упомянул папку “отпускных” приложений. У меня это AirBnB, TripAdvisor и Drimsim.
Заканчиваю на сегодня. Будет круто если в реплаях расскажете про свои самые часто используемые и любимые приложения. Доброй ночи!
Тред (Казаков Антон)
Воскресенье
@mobileunderhood OOM на разных машинах и на CI, на разных работах и проектах, на разных версиях линта. Как вариант, кстати, может намертво зависнуть ещё. Вот ща на проекте где всего 120 модулей и даже 300к строк кода нет, отрабатывает 20 минут и падает везде, где меньше 32гб оперативы.
У нас около 500+ модулей сейчас, Xmx 16G, maxworkers=6. Работает в контейнерах с лимитом на 24G памяти и 6 CPUs. Линт 27.1.2 с AGP 4.1.2. Думает конечно долго, но с ООМ не падает.
Локально линт гоняем только по измененным модулям - вполне допускаю что тут будет ООМ у многих. twitter.com/Andrey__Danilo…
Я бы попробовал:
- Попрофайлить линт таску градл-профайлером с Jprofiler каким-нибудь или посмотреть через VisualVM
- Тем же градл-профайлером запустил бенчмарк чтобы посмотреть как будет себя вести lint таска с другими jvmargs/gradle пропертями
- Если есть свои детекторы - посмотреть что в них все ок
- Если многомодульный проект, то включить checkDependencies
- Включить через только те детекторы из коробки, что нужны(enable/checkOnly)
- Даже если проблема с ООМ решится, запилить простенький импакт-анализ плагин(или взять готовый) и гонять lint только на измененных/заафекченных изменениями модулях
Если интересно могу скинуть gradle.properties, lintOptions и любую другую инфу. Пиши @antonkazakov в телеграме. Буду рад попробовать помочь)
Тред (Казаков Антон)
Сегодня воскресенье, а значит моя неделя в твиттере подходит к концу.
Очень жаль, что не получилось больше времени уделить тредам о любимых/нелюбимых технологиях.
Я бы с радостью поворчал про максимально неудобный процесс написания тестов в Андроиде, но похоже не в этот раз.
Спасибо всем кто участвовал в обсуждениях, голосованиях и просто читал.
С вами был Казаков Антон из Альфа-Банка. Твиттера у меня нет, поэтому если захотите пообщаться пишите в Телеграм t.me/antonkazakov. Я буду очень рад.
Всем пока🧡🧡🧡
@mobileunderhood @AntonKazakov Про ООМ я пожалуй чуть преувеличил - на 16 конечно не пашет, но с 24 пойдет. В целом вопрос скорее стоит ли сиайное время того, чтобы его расходовать на столь прожорливый линт, учитывая что явные нарушения подсвечиваются в самой студии при написании кода.
Хоть я уже попрощался, но не мог не ответить) twitter.com/Andrey__Danilo…
Я уверен что стоит.
Если доверять только локальным инспекшенам в студии, то CI перестает быть для нас single source of truth, благодаря которому мы уверены что в мастер попадает только проверенный и протестированный код.
Появляются недетерминированные билды, например, включен разный набор инспекшенов, либо разработчик просто упустил/забил на какой то ворнинг линтера и т.п. Факторов очень много.
Ну и в целом, у Android Lint есть довольно полезные проверки, которые могут предотвратить проблемы, начиная с простых codesmells, заканчивая потенциальными крашами в проде и просадкой производительности.
А "сиайное" время, которое тратится на Android Lint можно постараться минимизировать, опять же, за счет оптимизаций билда и импакт анализа.
Тред (Казаков Антон)
