Next Level Dev

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#android #работа

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

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

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

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

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

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

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

#android #работа

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#android #советы

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

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

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

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

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

#android #советы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Всем привет.

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

Channel photo updated

Channel created