Моя история. Часть 1

Будучи студентом, я был уверен, что программирование - не для меня. Я учился на Физтехе, собирался в науку, и меня всё абсолютно устраивало. Но когда я пошел работать в научный институт, я понял, что мне скучно, и перспектив у работы почти никаких. И тут я стал думать: а что дальше?

Тогда вокруг меня было много знакомых ребят-программистов, я посмотрел, как они кайфуют от работы, и понял, что тоже так хочу!
С помощью одного из таких друзей я по-быстрому освоил ООП и базовый уровень C++ и пошёл работать по знакомству программистом на пол-ставки. Дальше – ловкость рук, документация, гугл и никакого мошенничества: я копипастил код, который вроде как должен был решить мою задачу, бил в бубен и заставлял код работать.

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

Спустя несколько месяцев самостоятельного изучения я решил, что уже являюсь джуном, и устроился в мобильную студию. Но всё оказалось не так радужно: я в 4 раза превысил названный мной “от балды” срок разработки приложения, и после испытательного мне сказали, что с учётом такой скорости работы и низкого уровня моего кода они готовы платить мне в 4 раза меньше стандартной ставки джуниора - на этом мы с ними и расстались.

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

Ну а к чему это всё привело, я расскажу в следующий раз.

Моя история. Часть 2.

Итак, я вернулся к самостоятельному изучению android-разработки, параллельно с текущей работой.

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

Он оказался хорошим ментором, и многому меня научил: чем плохи “тяжёлые” public static переменные, и почему их не стоит держать в активити или синглтонах, что такое утечки памяти, как их находить и избегать, как построить стабильное REST-приложение с кэшированием и многому другому. Он показал мне, что действительно важно в профессиональной разработке, а что - дело вкуса, и как писать код так, чтобы другие смогли его понимать.

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

Но потом я осознал, что перестал развиваться и по уровню, и по зарплате, и я бросил все силы на прокачку своих скиллов, чтобы взять следующую ступень - миддла. Пришлось самостоятельно закрывать ряд важных пробелов: rx, корутины, даггер, паттерны проектирования, clean code. Ещё через полгода-год я уволился из компании и начал поиск работы, и спустя пару недель и несколько собеседований я устроился миддлом, а через 1.5 года стал синьором.

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

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

С чего начать андроид-разработку

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

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

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

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

#android #советы

Одна из главных ошибок, которую совершают джуны-разработчики

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

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

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

Например – я так когда-то сделал синглтон, в котором хранил большие коллекции с тяжёлыми элементами. А хранил его в нём, потому что больше не нашёл способа передавать данные из разных фрагментов в разные активити. Я не знал ничего ни о паттерне Repository, ни о Shared ViewModel, ни о Room, ни о Gson'е и Bundle. А синглтон, который кто-то предложил для решения похожей задачи на StackOverFlow, у меня сработал.

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

Хотите развиваться быстрее и эффективнее – найдите человека, который сможет вас вовремя откалибровать и поправить, если вы свернули не туда.

#android #советы

3 лучших книги для начинающего андроид-разработчика

1. Если хотите изучить Kotlin по книге – берём и штудируем книгу от основателей языка: "Kotlin in action". Если у вас есть опыт на Java или похожем языке – зайдёт на ура. Но нужно читать и одновременно пробовать писать код, иначе будет тяжко.

Если знания языков программирования у вас нет – говорят, лучше взять "Atomic Kotlin", но я не проверял. К тому же, один из двух соавторов там Брюс Эккель, Thinking in Java которого я не осилил (я не любитель фундаментальных книжек, люблю что-то полаконичнее и попрактичнее).

В целом, книги по Kotlin я бы рекомендовал использовать скорее как методички, или читать оттуда избранные главы. А так - изучение языка я бы начинал с kotlinlang.org, но это уже другая история.

2. Книга "Чистый код" Р. Мартина для меня не устареет никогда, кто бы что ни говорил. Я уверен, что прочитать её необходимо, потому что попытки следовать советам этой книги однозначно улучшают качество кода новичка. Читается она очень легко.

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

3. А вот книгу "Head First. Паттерны проектирования" вам нужно прочитать совершенно точно безо всяких "а стоит ли". Без знания этих основных паттернов писать код на профессиональном уровне вы просто не сможете, и дальше джуна не пробьётесь точно, да и на джуна только с большой удачей. Книга написана легко и понятно. Если уже знаете Java и/или Kotlin и не читали - читайте немедленно.

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

Сколько зарабатывает андроид-разработчик

1. Junior: от 50 000р до 80 000р в месяц.
Зависит от того, сколько задач в компании на вас нагрузят, и от того, будете ли вы единственным разработчиком. Эти два фактора обычно немного повышают оклад, но вы должны понимать, вывезете ли вы такие нагрузки, и сможете ли эффективно развиваться в одиночку. Хотя, если это первая работа, выбора обычно нет - идёшь, куда берут.

2. Middle: от 120 000р до 200 000р в месяц.
Тут вилка становится шире, потому что миддлам в разных компаниях поручают разные задачи и области ответственности. Где-то миддл - винтик в большой машине из джунов/миддлов/синьоров, а где-то - это самый опытный в команде или даже единственный её член, на котором полностью завязан процесс разработки.

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

3. Senior: от 250 000р до 450 000р в месяц.
Тут вилка ещё шире, потому что синьор, помимо крутого кода, может заниматься менторингом джунов/миддлов, собеседованиями, продвижением бренда компании: участвовать в конференциях, писать статьи, книги. Синьор часто является поддержкой тимлида/техлида и выполняет часть их обязанностей.

Чем больше таких областей ответственности вы сможете покрыть - тем больше вам будут готовы платить.

P.S.: Ну и не стоит забывать, что ваш оклад и грейд (джун/миддл/синьор) сильно зависят от того, как вы сможете подать себя на собеседовании. Об этом напишу подробнее в следующих постах.

#android #работа

Какими задачами обычно занимается джун?

Если вкратце - джуну дают небольшое задание и вкидывают его в процесс разработки.

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

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

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

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

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

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

#android #работа

Писать ли сразу чистый код с правильной архитектурой?

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

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

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

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

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

#android #архитектура #лайфхаки

Что учить: RX или корутины?

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

Если вы метите в миддла - важно также понимать, зачем вообще многие переходят на корутины, когда у них есть RX. И простого «ну они легковесные» недостаточно - вы должны показать, что реально на своей шкуре ощутили преимущества и недостатки того и другого.

И самое важное: корутины и RX - это разные реализации многопоточности. Прежде, чем приступать к ним - сначала научитесь отличать шедулер от диспатчера, а трэд от процесса. И про дэдлоки почитать не забудьте :)

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

Продуктовая разработка vs галеры

Есть два фундаментельно отличающихся вида разработки: продуктовая и проектная.

Продуктовая разработка — когда у компании есть один или несколько продуктов, которыми она полностью владеет, развивает, и получает с них доход. Каждым продуктом занимается или целое отделение большой компании, или вся компания. Например, приложение Yandex GO, или приложение BelkaCar.

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

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

Проектная разработка — компания разрабатывает приложение по заказу: заказчик формирует ТЗ и дедлайн, компания делает приложение по этому ТЗ, а потом отдаёт этот проект заказчику и забывает. Все права на приложение, на код, весь заработок с приложения — всё принадлежит заказчику.

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

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

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

Куда идти - решать вам. Поскольку в проектную разработку, а тем более на галеры, попасть куда проще, чем в продуктовую, то некоторые начинают с этого. Главное - понимать, зачем вы идёте в эту «мясорубку», и не разочароваться в профессии, подумав, что разработка везде такая, как там.

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

Распространённая ошибка джунов

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

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

Анализируйте свои вопросы и причины их возникновения. Старайтесь объединять их, искать корневую причину и решать её, а не вопросы по отдельности. Как это сделать?

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

Например:
1) вы не понимаете, почему у вас контейнер фрагмента перекрывает тулбар активити
2) вы не понимаете, почему у кнопок обрезается тень
3) вы не понимаете, почему в некоторых приложениях всё выглядит объёмно, красиво, «друг под другом», а у вас всё на одной плоскости и некрасиво.

Проблема тут одна – непонимание того, что такое elevation. Нужно максимально глубоко копнуть, как именно он в приложении работает, и что с его помощью можно делать. Начать с документации, примеров кода, закончить статьями или даже главами книг.

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

P.S.: а какие у вас трудности сейчас? Пишите в комментариях, разберёмся вместе.

#android #ошибки

Не играйте в героя. Или как осилить первое задание?

Итак, тимлид дал вам первое задание. Как к нему подступиться?

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

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

а) сделали что смогли и как смогли, упёрлись в проблему

б) попросили помощи

в) вас скорректировали, подсказали

г) вы пошли работать над задачей дальше

Например: “Мне надо выкачать репозиторий. А, нужны доступы: пошёл к лиду узнавать. Так, надо в фигме вёрстку глянуть. А, опять нужны доступы – пошёл узнавать. Так, теперь работаем. Хм, а как авторизоваться в приложении? Спрошу у команды. Так, работаем. Хм, а вот тут во вьюмодели какая-то странная логика, которую я не понимаю, а мне её надо дополнить – пойду-ка уточню у команды, чтоб ничего не запороть. Так, а как реквесты создавать? Командааа…”

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

Плохие варианты:

а) прийти с неконкретным вопросом: "Я не знаю как делать эту задачу" вместо "а как проверить 500-ю ошибку сервера?" или "гит не даёт скачать репозиторий"

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

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

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

Как устроиться на работу, или "Где мои 300к/наносекунду?!"

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

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

Лайвкодинги бывают разные: могут дать задачки на алгоритмы, могут дать порефакторить плохой/не работающий код, или дать простую задачу типа "Вот метод из API, напиши необходимые классы для отображения контента из этого метода".

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

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

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

А были ли у вас на собеседованиях вопросы, которые вводили в ступор?

#android #работа #собеседование

Тварь ли я дрожащая или в разработку сумею?

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

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

Зависать на чём-то непонятном для вас – это нормально. Процесс познания не идёт бесшовно. Не бойтесь долго думать и изучать вещи, которые «казалось бы простые» – поверьте моему опыту: многие проходят мимо таких вещей, посчитав их «как бы понятными», но спроси их поглубже – найдёшь непонимание. Даже если у них 5-10 лет опыта. Так что не стесняйтесь искать ответы на простые и «глупые» вопросы, они углубляют ваше понимание и дают прочный фундамент для дальнейшего познания.

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

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

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

#android #советы

Как осилить сложное задание?

Тимлид дал вам задание, а оно кажется вам сложным, и вы без понятия, как его сделать.
Как к нему подступиться?

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

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

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

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

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

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

2) Если задача срочная — тогда лид должен поручить другому члену команды эти непонятные вам части.

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

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

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

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

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

1. Выдержать баланс между простотой и демонстрацией навыков.

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

2. Делать задание самому.

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

3. Сделайте задание за разумный срок или быстрее.

Если вам говорят «да за сколько сделаешь, за столько и сделаешь» - это не означает, что можно на расслабоне делать задание столько, сколько хотите. Постарайтесь или на собеседовании добиться хотя бы среднего ожидаемого времени, или оценить его сами, если вам хватает компетентности. Если понимаете, что не сможете приступить сразу – обязательно скажите об этом. Скажите «приступлю через 3 дня, в четверг вечером». На тестовое задание редко тратят больше 3-5 дней. Не надо сидеть над ним по 10+ дней. Но не надо и спешить отдавать сырой проект на следующий день.

4. Сразу продумайте структуру приложения.

Делайте так, как написано в ТЗ. Если не написано – уточните у работодателя, есть ли у вас карт-бланш на любое решение.

По структуре обычно предлагают делать всё по Clean, в отдельных слоях. Со своими учениками я дополнительно отделяю presentation, domain и data в отдельные модули, если вам хватает навыков и времени – сделайте так же.

Для презентейшн-слоя я рекомендую MVVM, как самую распространённую и несложную.

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

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

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 #лайфхаки