7 принципов подготовки тестового задания. Часть 2.

5. В каком порядке что писать?

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

Потом реализуем всю необходимую вёрстку.

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

6. Проверка работоспособности.

Желательно успеть проверить работу приложения на реальном устройстве, не только на эмуляторе. Можете написать в Readme, на каком устройстве проверяли.

7. Readme

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

P.S.: если вам нужна помощь с тестовым заданием - пишите мне в личку или в комментарии.

#android #работа #советы

Если гора не идёт к Магомету, Магомет идёт прочь

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

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

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

И тут мне в голову пришла крамольная идея: раз моё сознание не справляется, значит, делегирую работу подсознанию. Я пошёл, бахнул валерьянки, после чего завалился спать посреди рабочего дня. Прямо так, переборов сильное чувство стыда за это. Засыпал я с мыслью "так, будильник я не ставлю, и буду спать, сколько потребуется для того, чтобы задача была решена".

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

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

#android #лайфхаки #советы

8 удобных хоткеев в Android Studio

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

1. Ctrl + B (⌘ + B). B можно заменить кликом мышкой.

Перейти к месту объявления класса/метода/переменной.
Также работает как переход к месту пакета в дереве проекта, если кликнуть на название пакета, который есть на 1 строке любого файла.

Если этот хоткей использовать на названии интерфейса, вы перейдёте к списку использований интерфейса: куда его инжектят, где его байндят, где его реализуют. Если же вы хотите не этого, а перейти к конкретной имплементации интерфейса - на это есть хоткей
Ctrl + Alt + B (⌘ + ⌥ + B)
На методах интерфейса это тоже работает.

2. Ctrl + Alt + O (⌃ + ⌥ + O)

Убрать неиспользуемые импорты в классе.
Чтобы не удалять вручную все эти серые импорты.

3. Ctrl + Alt + L (⌘ + ⌥ + L)

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

4. Shift + F6 (⇧ + Fn + F6)

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

5. Ctrl + Shift + F (⌘ + ⇧ + F)

Поиск строки в указанной папке (предварительно на неё надо кликнуть в дереве проекта).
Если помните на экране какую-то строку, но не помните, как называется сам экран - таким образом сможете его найти.
Если строку нужно не просто найти, а заменить во всём приложении на другую - на это есть хоткей
Ctrl + Shift + R (⌘ + ⇧ + R).

6. Alt + F7 (Fn + F7 + ⌥)

Найти все места использования.
Работает на переменных, классах, айдишниках в xml. Особенно удобно на строках: находите строку в strings.xml, используете на ней хоткей - и видите, где она используется.

7. Shift + O (⌘ + O)

Искать класс по его названию.

8. Ctrl + Z (⌘+ Z)
и Ctrl + Shift + Z (⌘+ ⇧ + Z)

Отменить последнее действие (шаг назад)
и
Вернуть отменённое действие (шаг вперёд)

С помощью этих двух хоткеев можно быстро "перемещаться во времени", если вы вдруг что-то стёрли, а оно потом понадобилось.

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

#android #лайфхаки

Бесплатный поэтапный Roadmap Android-разработчика с нуля до Junior

Друзья, подготовил для вас ёмкий и подробный гайд, как развиваться с нуля до джуниор андроид-разработчика.

Гайд поможет начинающим разобраться в большом объёме информации и понять, на что стоит обратить внимание, куда надо углубиться, где можно пройтись поверхностно, а чего стоит избегать.

Этот гайд - концентрация моего 9-летнего опыта работы, собеседований и менторинга андроид-разработчиков.

Как получить гайд: напишите мне в личку "хочу роадмап" и я вышлю вам ссылку.
Желаю вам продуктивного обучения и развития :)

#android #работа #роадмап

Paging3 - дар или проклятие?

Рано или поздно начинающий разработчик сталкивается с понятием «пагинация» – постраничная загрузка контента. Разумеется, он идёт искать существующие для этого решения, и неизбежно находит библиотеку Paging3.

Он думает:
«Ура! Эта штука решит проблему пагинации под ключ! На обучающих видео всё делается быстро, удобно и красиво! Документация понятная и с примерами! И это даже не внешняя библиотека, а из гугловского джетпака!».

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

Поначалу вам понравится и всё покажется удобным. Потом столкнётесь с визуальным багом, и найдёте костыльное решение. Потом с ещё одним. Потом поймёте, что вы можете на 80% решить все свои задачи красиво, но для оставшихся 20% вам нужно вставить 20 отвратительных костылей. Потом, если вы уже умеете в Clean, обнаружите, что Paging3 расползся у вас по всем слоям, заставил вас отсылать ряд избыточных ивентов во вьюху, вынудил ввести костыльные флаги и заводить стейты там, где они быть не должны.
И в этот момент вы поймёте, что Paging3 вас победил, и условия давно диктует он. И придётся решать, стоит ли оно того.

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

Кроме того, для начинающих я категорически советую сделать сначала пагинацию вручную через ScrollListener. С кэшированием и взаимодействием с сетью, с вьюмоделью, и желательно с чистой архитектурой. Увидеть, как оно всё работает, и какие есть проблемы. И только потом попробовать Paging3, чтобы сделать осознанный выбор: от него больше пользы или проблем.
Но ознакомиться с Paging3 я всё же советую, в некоторых компаниях его используют.

А был ли у вас опыт Paging3 в проде? Расскажите, очень любопытно.

#android #лайфхаки

❇️ видео про парсинг API ❇️

https://youtu.be/-qCv3jEoFzA?si=5vy_5YGdHBDdy0lZ

#android #видео #лайфхаки

Как джуниору стать миддлом?

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

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

1️⃣ работал ли он в команде с продактами, проджектами, айосерами, бэкендерами, дизайнерами, тестировщиками? Принимает ли он процессы разработки, не будет ли саботировать их?

2️⃣ участвовал ли в перекрёстных код-ревью, умеет ли доносить свои мысли до коллег и принимать критику?

3️⃣ были ли у него конфликты и факапы, как выходил из этих ситуаций?

4️⃣ достаточно ли глубоки его знания об архитектуре? Понимает ли он, для чего это всё, когда это избыточно, а когда нет, и как применять в конкретных бизнес-ситуациях? Может ли он рассказать об этом на своём опыте, а не из книжек?

5️⃣ может ли рассказать об именно своих значимых вкладах в разработку в команде? Не абстрактно: "участвовал в разработке фич", а конкретно: "самостоятельно провёл рефакторинг главного экрана с MVP на MVVM".

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

P.S.: если вам интересно, какие навыки нужны, чтобы стать джуном - ответ тут.

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

#android #работа #советы

🚀 Скидка 15% на менторство на https://androidmentor.ru/ 🚀

Привет, друзья!

Новый Год – время подводить итоги прошедшего года и ставить цели на следующий. Я в этом году, помимо основной работы, активно занимался менторством начинающих андроид-разработчиков, и довёл нескольких ребят до устройства на работу джуниорами. Но до конца года ещё целых 155 часов, и не знаю как у вас, а у меня порох в пороховницах ещё есть, поэтому:

Для всех, кто за этот год ещё не успел стать андроид-разработчиком, у меня есть отличная новость:
🔥 в честь Нового года я даю всем желающим скидку 15% на все свои тарифы менторства.🔥

✨ Что вас ждёт:

1️⃣ Начальное собеседование-скрининг и индивидуальная программа обучения

2️⃣ Быстрая и тщательная обратная связь, жизненно необходимая для эффективного развития

✅ Результат:
Заточенное именно под вас обучение и менторская поддержка, обеспечивающие максимально эффективный рост и быстрое достижение целей

Подробнее о менторстве на моём сайте.

Но и это ещё не всё.

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

Записаться на менторство / консультацию со скидкой можно сейчас, а начать в следующем году.

Если вы готовы начать Новый Год продуктивно вместе со мной – приходите в личку.

#android #менторство

Отзыв на менторство

Привет, друзья!

Это отзыв одного из моих менти, с которым мы занимались в этом году.

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

Что мы сделали:

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

🎉 Вскоре Александр устроился на новую работу андроид-разработчиком.

Если хотите ускорить свой путь до устройства на работу – приходите ко мне на менторство. До нового года действует скидка 15%.

Подробнее о менторстве и запись: https://androidmentor.ru/

#android #менторство

@andrdevnotes

Как бы я развивался в андроид-разработке с нуля в 2024 ?

Если представить, что у меня остались все мои знания о мире, но все софты/харды в IT пропали, а мне снова 18 – как бы я строил свой профессиональный путь в 2024 ?

1️⃣ Освобождаю себе максимум времени.
Поступаю в институт попроще, чем МФТИ. Лишь бы дали общежитие.

2️⃣ Учу kotlin.
В институте учился бы спустя рукава, и всё время бы тратил на изучение kotlin.

3️⃣ Устраиваюсь на kotlin-стажировку: коплю деньги на ментора и набираюсь знаний о том, как работает IT-компания внутри.
Подойдёт стажировка в любой IT-компании на вакансию с kotlin. В идеале – андроид, но необязательно, можно и бэкенд.

4️⃣ Выбираю ментора, развиваюсь до джуна.
Через несколько месяцев, когда накопил денег, ушёл бы со стажировки, выбрал бы себе хорошего платного ментора, пришёл к нему с запросом "kotlin знаю, доведи меня до андроид-джуна".
Ещё несколько месяцев плотной работы с ментором – и можно идти на собеседования.

5️⃣ Выбираю сферу, работаю, развиваюсь до миддла.
Важно выбрать сферу с самого начала, и желательно не менять её хотя бы несколько лет. Чем больше вы работаете в какой-то сфере – тем быстрее вы там развиваетесь и накапливаете метанавыки, которые выгодно отличают вас от тех, кто только приходит в эту сферу. Прыгать из одного банка в другой – нормально, а вот прыгнуть из банковской сферы в транспортную – тут уже придётся с нуля погружаться в новую сферу - а это затраты времени.

Итак: работаю джуном, а параллельно, для ускорения процесса, продолжаю развивать навыки с ментором, пока не стану твёрдым миддлом.

6️⃣ Синьор-ментор.
Дальше – дело техники. Коплю опыт, развиваю софты, становлюсь синьором. А дальше – ментором.

🏁 По моим прикидкам, такой путь занял бы у меня 5 лет вместо 10 к той точке, где я сейчас, и начал бы я его в 18, а не в 21. И я бы был тем самым мемным 23-летним синьором-ментором :)

Мой самый большой страх перед первой серьёзной работой

Я помню, как в первую ночь перед выходом на работу, я судорожно сидел и пытался понять: а как вообще ведётся командная работа? Каким образом несколько андроид-разработчиков одновременно работают над своими задачами?

Я знал, как работает гит на уровне commit/push в мастер и всё.
Я не знал о подходах с отдельными ветками, пулл-реквестами, лишь что-то слышал краем уха о код-ревью. Но я так и не смог найти ответ на вопрос, а где и как этот загадочный код-ревью проходит.

Тогда я впервые услышал про какой-то гит-флоу. Советую почитать и оригинальную статью и её критику.

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

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

#android #работа #советы

Как выглядит работа андроид-разработчика в продуктовой команде?

1️⃣ Тот код, что в продакшне (то есть у пользователей), всегда лежит в мастер-ветке. Код, который вы пишете, окажется в мастере только в самом конце вашей работы над задачей, после код-ревью, тестов и релиза в стор. До этого он будет существовать в отдельной ветке, которая будет ревьюиться и тестироваться.

2️⃣ Вам приходит таска в таск-трекере (Jira, Miro, etc.), например «Интегрировать новый дизайн на экране авторизации».

3️⃣ Вы от мастера ответвляете свою ветку под эту таску.

4️⃣ Пишете в этой ветке свой код для таски.

5️⃣ Коммитите/пушите изменения в своей ветке и создаёте из ветки пулл-реквест в гитхаб.

6️⃣ Этот пулл-реквест уже смотрят ваши коллеги из андроид-команды — это и есть код-ревью. Ваш код комментируют, при необходимости предлагают что-то изменить или исправить — в таком случае вы вносите изменения и делаете новый коммит-пуш в эту ветку и отдаёте на ревью заново.

7️⃣ После того, как коллеги решили, что ваш код в порядке - они ставят "Approve" пулл-реквесту, и после этого вашу ветку можно отдавать в тестирование. В зависимости от договорённостей в команде и её размера, вам может потребоваться один или несколько аппрувов.

8️⃣ Если тесты прошли успешно - ваша ветка мёрджится в релизную ветку, если нет - идёте вносить исправления и снова отдавать на код-ревью.

9️⃣ Релизная ветка — та, которая пойдёт в стор, и сразу после этого смёрджится в мастер. В релизную ветку сливаются все ветки, которые проревьюены, протестированы и готовы к публикации в стор.
Важно: перед тем, как мерджить свою ветку в релизную, вам может понадобиться исправить мердж-конфликты. Они возникают, если в одном и том же месте в двух ветках были внесены разные изменения, и вам нужно определиться, что с этим делать: заменить одно изменение другим, или добавить и то и другое, или каким-то ещё образом выйти из этой ситуации, не сломав логику обоих изменений. Это можно делать или внутри Android Studio, подлив релизную ветку в свою, а потом исправить конфликты и запушить итоговые изменения в свою ветку, или в самом гитхабе в пулл-реквесте.

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

#android #работа #советы

@andrdevnotes | androidmentor.ru

Бесконечные муки или источник кайфа?

На пути разработчика вам придётся привыкнуть к одной простой мысли: ваши усилия != количество написанных строк кода. Иначе оценка труда разработчика и его оплата была бы куда проще и прозрачнее.

Когда-то я считал иначе. И на полном серьёзе думал, что увеличение скорости печати сделает меня лучшим профессионалом :)

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

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

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

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

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

А сколько вы кода при этом напишете – не так важно. По сути, чем меньше кода – тем лучше. Не тот крут, кто пишет 1000 строк кода в день, а тот, кто 100 строками кода решает ту же задачу, что менее опытный за 1000 строк :)

#android #советы

@andrdevnotes | androidmentor.ru

Надо ль вам идти с понятного пути в непонятное IT?

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

И главное – работа у меня была максимально ненапряжная, никто не следит и ничего не требует. Можно заниматься чем угодно на работе под видом исследований. Хочешь – сидишь и осваиваешь другую удалённую профессию, хочешь - залипаешь в соцсети или книжки читаешь. Почему же я ушёл?

Оказалось, что это очень разлагающая среда. Никому вокруг ничего не надо, и тебе тоже становится не надо. Тебя засасывает в это болото. В итоге дни пролетают почти бесполезно, хотя кажется, что свободного времени – вагон. Но твой КПД невероятно мал.

Почему я ушёл из науки?
Потому что потолок белой зарплаты там был
100 000р через несколько лет упорного труда, что меня не устраивало.

Почему я ушёл из науки?
Потому что я месяц почти не появлялся на рабочем месте, а после возвращения я услышал лишь «о, а ты не в отпуске был? Ну ладно». И я понял, что моя работа здесь никому не нужна.

Совсем по-другому в IT. Здесь у тебя постоянно горит земля под ногами от того, что тебе со всех сторон твердят: то, что ты знаешь, уже никому не нужно. Это вам не НИИ, тут знания протухают очень быстро. И ты вместе со всеми бежишь вперёд и развиваешься.

Идти ли вам в IT? Нет, если вы не готовы пахать. Первые полгода – год в обучении, хотя бы по 4 часа в день, а потом ещё год-другой в команде, пока не станете крепким миддлом. А там вас уже затянет, если до тех пор не сольётесь.

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

#android #советы

@andrdevnotes | androidmentor.ru

Подкаст от деды в IT:
Стажировки, джуны, начало пути в IT, менторство

Два андроид-разработчика:
Senior (я) и Lead (https://t.iss.one/LeadTales)
обсудили, как нынче стать джуном и всё вокруг этого.

Пока только на Spotify, поэтому запускать под VPN.
Позже, думаю, перенесём на более удобный хостинг и выложим на другие сервисы.

Жду вашей обратной связи: что отозвалось, что стало неожиданным открытием, а с чем бы вы поспорили?

@andrdevnotes | androidmentor.ru

Привет, друзья!
Подкаст стал доступен на apple-подкастах и яндекс-музыке, залетайте по новой ссылке

#android #подкаст #работа #советы

https://veterans-in-it.mave.digital/