«Всю веб-разработку медленно поглощает хаос»: как я проработал с Android 10 лет и почему больше туда не вернусь

В своей статье на Medium разработчик и архитектор Мартин Новосад объясняет, почему он навсегда оставил Android-разработку после почти 10 лет работы в этой сфере. Но сначала немного расскажет, как строил свою карьеру.

Передаем ему слово.

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

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

Я помню времена, когда RxJava была новинкой. Помню, как разработчики (привет, Джейк Уортон) говорили о новом языке Kotlin. Я помню, как Kotlin становился все популярнее и менял область Android-разработки.

Помню, как появлялись корутины, которые сначала воспринимались как «убийцы RxJava» («Эй, теперь вы можете писать весь асинхронный код синхронизированным способом! Нет нужды в потоках!»).

Очаровательная идея, но несовершенная. Но низкоуровневые асинхронные примитивы, такие как Channels, стали Rx-Way для Kotlin.

Помню веселые разговоры с моим коллегой Дэвидом о состояниях и событиях. Что такое состояние и что такое событие? Что событие делает с состоянием и наоборот?

Я помню, как не спал всю ночь, чтобы выучить Dagger 2: это было еще до того, как ее заменили Koin и Dagger Hilt. Помню, как впервые прочитал книгу «Чистая архитектура» дядюшки Боба: определяющий момент, повлиявший на мою карьеру.

Теперь я мог разрабатывать и писать почти все приложения, не думая о MVVM/MVP/MVC или каких-либо других деталях, специфичных для платформы. Я узнал, почему тестирование важно, я попробовал TDD, полюбил и возненавидел его. Я узнал DDD и BDD.

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

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

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

Я работал над сложными приложениями с интенсивным шифрованием E2E, связью с датчиками, чипами NFC, маяками BLE, приложениями для чата с высоким трафиком и легендарными приложениями для списков дел.

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

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

Мне повезло, что за последние четыре-пять лет я иногда работал над бэкенд-частью проектов моих клиентов. 

Я потратил много времени на то, чтобы понять тонкости разработки бэкенда:

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

Я рефакторил системы Java EE в Go. Глядя на полученный двоичный файл, скомпилированный Go, оценивая, как он использует память и насколько незначителен был используемый объем, я понял, почему Go так популярен.

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

Действительно ли Android — то, что мне нужно?

Впоследствии я устал от всех встреч с UI/UX-дизайнерами и объяснения основ материального дизайна или почему мы не можем вызвать просто так поведение X в приложении Y.

Я помню, как часами говорил о проектах, что приводило к тому, что мой мозг в конце концов выключался. 

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

Почти всегда основной вызов — это UI-уровень, который постоянно становится другим из-за смены API фреймворка. На UI оказали большое влияние UI/UX-дизайнеры и POs.

В последнее время почти все мои проекты превратились в повседневную работу. Речь шла не столько о разработке, сколько о бизнесе, а процесс работы чаще всего был связан с Android API.

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

Я думал: зачем мне это? Конечно, деньги — это хорошо. Но скоро мне будет 30 лет. Вижу ли я себя в этой области?

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

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

Упадок Android-разработки

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

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

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

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

Теперь в моих планах есть то, о чем я не думал, когда занимался Android:

• получить сертификаты k8s;
• стать специалистом, работающим с несколькими облаками;
• изучить плюсы и минусы конкретных баз данных;
• углубить свои знания в DevOps.

Я чувствую, что мне снова интересно работать, потому что есть сложные инженерные проблемы, которые нужно решать.

Грустно, но простой Android-разработчик вряд ли сможет стать архитектором или инженером (неважно, руководящая должность или нет). У него просто нет необходимых навыков. 

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

Автор: Мартин Новосад

Текст адаптировала Евгения Козловская