Почему я бросил Android-разработку после 10 лет и чем планирую заниматься сейчас

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

Старые добрые времена

Я начал Android-разработку в 2013 году, когда еще Android 4.4 был популярной новинкой. Когда AsyncTasks еще были стандартом, когда у нас был OttoEventBus и другие ужасные вещи. Я был свидетелем того, как архитектурные тренды меняются от MVC к MVP/MVI, затем к MVVM и, наконец, к сочетанию MVVM/MVI.

Я помню, когда RxJava была новинкой на рынке, и все внезапно стало реактивным и потоковым. Я помню, как l33t-ные Android-разработчики (привет, Джейк Уортон) говорили о новом языке неудачников под названием Kotlin. Я помню, как Kotlin поднялся и захватил Android-индустрию. Я помню, как появлялись корутины, и сначала они казались большими убийцами RxJava (Эй, теперь вы можете писать весь асинхронный код синхронно! Нет необходимости в потоках!). Очаровательная идея, но довольно быстро оказалось, что это просто хорошая идея. Поэтому низкоуровневые асинхронные примитивы, такие как Channels, стали Rx-методами для Kotlin. О, эй, оказывается, многие люди выстрелили себе в ноги с помощью Channels. Пришлось заново представить идею бережливых холодных и горячих потоков — StateFlows и SharedFlows. В итоге у нас есть облегченная, идиоматическая версия RxJava2 на языке Kotlin с поддержкой корутинов.

Я помню, как весело беседовал с моим коллегой Дэвидом о Состояниях и Событиях. Что такое Состояние (State) и что такое Событие (Event)? Что событие делает с состоянием и наоборот? Я помню, как не спал всю ночь, чтобы выучить Dagger 2, за годы до того, как его заменили Koin и Dagger Hilt. Я помню, как впервые прочитал «Чистую архитектуру» дяди Боба, и это был один из самых ярких моментов в моей карьере Android-разработчика. Теперь я мог проектировать и писать почти все приложения, не задумываясь о MVVM/MVP/MVC или любых других деталях, специфичных для платформы. Я узнал, почему тестирование важно, я попробовал TDD, полюбил и возненавидел его. Я узнал о DDD и BDD.

Мой поезд достиг конечной станции?

(Я выбрал этот подзаголовок, потому что пишу эту статью прямо сейчас в поезде, который идет из Швейцарии в Германию)

Со временем я неожиданно оказался в положении, когда стал руководить командами на крупных предприятиях, таких как Porsche или IBM. Это была отличная поездка, и я чувствовал, что после 6-7 лет опыта достиг того, чего хотел. Я работал над сложными приложениями с тяжелым E2E-шифрованием, связью с датчиками, NFC-чипами, BLE-маяками, приложениями для чата с высоким трафиком и это не говоря уже о таких приложениях, как легендарные приложения со списками дел.

Примерно через 6 лет я начал присоединяться к проектам в качестве ведущего Android-разработчика. Я научился определять основные технические проблемы, от которых страдает большинство проектов, над которыми я работал (архитектура и члены команды по-разному понимают определенные шаблоны). Я узнал, как научить команду решать эти проблемы и успешно завершать проекты. Все новое, что меня ждало сейчас, — это изучение новых изменений API/фреймворков для решения задач, которые мы решаем уже много лет. Только на этот раз новый фреймворк/API справляется с этим лучше (больше нет ручной обработки жизненного цикла, обработки транзакций фрагментов, XML-макетов и т.д.).

Мой предыдущий опыт работы с бэкендом

Мне повезло, что за последние 4-5 лет я смог работать над бэкендом проектов моих клиентов (по их запросу). Я потратил много времени, чтобы понять все тонкости бэкэнд-разработки, написания параллельного кода, создания распределенных систем, масштабирования по вертикали и горизонтали, обработке распределенных транзакций, написания конфигурируемого кода, который ведет себя так, как ожидается в разных средах, работы с  разными типами баз данных (граф, реляционные, документные) и какую базу данных использовать для каких данных, работы с docker и k8s. Я преобразовывал системы Java EE в Go. Глядя на полученный двоичный файл, скомпилированный Go, его использование памяти и почти несуществующий объем, я понял, почему Go такой удивительный. Проблемы, которые я решал как бэкенд-разработчик, не шли ни в какое сравнение с проблемами, с которыми я сталкивался на Android (о них я расскажу чуть позже). Проблемы, которые я решал как бэкенд-разработчик, оказали на меня большее и более глубокое влияние, чем танцы вокруг пикселей на Android.

Правда, Android, и это все?

В конце концов, мне надоели все встречи с UI/UX-дизайнерами и объяснение им основ Material Design или почему мы не можем “просто” сделать поведение X в приложении Y. Я помню, как часами говорил о дизайне, что в конце концов приводило к тому, что мой мозг отключался. Это произошло в нескольких проектах, некоторые из которых имели определенную степень сложности. Как только команда понимала «Чистую архитектуру» и Domain Driven Development, нам удавалось писать уровни предметной области и данных за очень короткое время. Как только вы демистифицируете различные потоки аутентификации для команды, правильная логика обновления токенов становится простой задачей. Основной проблемой почти всегда становится уровень пользовательского интерфейса, который постоянно меняется из-за меняющихся API фреймворка. Уровень пользовательского интерфейса находился под сильным влиянием UI/UX-дизайнеров + PO. В последнее время почти все мои проекты сливались в повседневную работу, которая почти вся была связана не столько с проектированием, сколько с бизнесом, а затем с исполнением, которое почти всегда связано с Android API. В лучшем случае это была относительно свежая задача, такая как написание кастомного View и использование некоторой линейной алгебры, но в целом — почти всегда — это было что-то скучное. Размышляя обо всем этом, я спрашиваю себя: что в этом для меня? Я зарабатывал хорошие деньги — конечно. Но мне вот-вот исполнится 30 лет, кем я вижу себя в ближайшие годы?

Как опытного Android-разработчика, меня можно использовать только на позициях, связанных с Android. Все мои навыки были построены на разработке поддерживаемого, чистого кода, который правильно работает на платформе Android. Код, который уничтожается сборщиком мусора, как и ожидалось, и код, который выживает, потому что он предназначен для этого. Что, если Android скоро исчезнет? Глядя на замечательную технологию, такую ​​как Flutter, а также работая с ней над некоторыми замечательными приложениями, я бы не стал начинать какой-либо новый проект в виде отдельных нативных приложений для iOS и Android. И, честно говоря, набор навыков, который вы развиваете, имеет меньшую ценность для должности главного/штатного инженера-программиста в большинстве компаний.

Закат Android-разработки

Я успешно завершил свой последний проект, но пришло время что-то изменить. Я больше не хотел участвовать в многодневных дискуссиях о границах CardView или повторяющихся бессмысленных вещах, таких как использование радиобаттонов или чекбоксов. Я больше не хотел изучать новые библиотеки Android, чтобы лучше справляться с жизненным циклом Android или обрабатывать навигацию только для того, чтобы ее снова заменили в течение следующих 12+ месяцев. Я делал это уже несколько раз за последние 10 лет. Каждое новое поколение разработчиков чувствует, что у ему надо написать новую библиотеку для обработки состояния пользовательского интерфейса или новую библиотеку для навигации. Тесты? Неа. К сожалению, многие разработчики используют эти библиотеки. Android-разработка медленно поглощается хаосом, который поглотил веб-разработку (Вы пробовали установить create-react-app приложение? Вы загрузите тысячи библиотек, включая некоторые уязвимые).

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

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

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

Спасибо, что прочитали эту статью. Я хотел бы услышать ваше мнение в разделе комментариев

Источник