Введение
Данная статья, скорее статья-вопрос к читателю. Может кто-нибудь сталкивался с подобными размышлениями. Зачастую комментарии к статье интереснее самой статьи :).
В ИТ с 2010 и прошел путь от С++, десктопа до мобилок, бэкенда и фронтенда, возраст 35+. В данный момент на позиции старший разработчик в небольшой компании занимаюсь фронтом на Angular, параллельно есть опыт бэкенда на GoLang и нативной мобилки под Андройд. И вот прям нахожусь на перепутье: а что дальше? Куда и как развиваться в карьерном плане? Развиваться вширь, где везде по чуть-чуть или все таки выбрать узкое направление и смотреть в сторону крупной компании? Но и какое само направление выбрать?
Android
С Андройд начал наработать с 2015 - времена Java, AsyncTask и Rx. С самого начала когда начал работать с Android был поражен, если так можно сказать, незрелостью разработки на платформе. Вот вроде бы есть Android SDK - стандартный кит, но много чего нет из коробки и нужно использовать библиотеки, которых огромная куча и качество некоторых не очень. Просто что вспомню: работа с HTTP (android-async-http, Volley от Google, OkHttp, Retrofit и другие), загрузка изображений по сети (Glide, Coil и другие).
Организация кода самого приложения. Сначала это классический MVC, где Activity или Fragment - это толстый контроллер и вью одновременно. Потом пошла мода на MVP (Model-View-Presenter), MVI (Model-View-Interactor), Clean Architecture и другие. Параллельно Google обновляет свои туториалы (об этом поговорим отдельно) и предлагает свою архитектуру MVVM (Model-View-ViewModel), где в составе нее предлагает свой реактивный подход через LiveData. Я в основном работал с MVC и MVVM архитектурами. Добавим сюда еще такие либы от Google как: DataBinding (не использовал), ViewBinding (не использовал), Paging (не использовал), X, Y, Z... (не использовал)...
Параллельно начинает развиваться Kotlin, корутины, Flow и другие фичи и библиотеки. В итоге происходит еще один сдвиг: отказ от Rx в пользу корутин и Flow, пока еще рекомендуемая от Гугла архитектура это MVVM, но вместо LiveData уже Flow и корутины. Также не забываем, что начиная с определенного момента рекомендованным подходом становится Single Activity подход - одна активити и много фрагментов для экранов приложения. Для этого подхода тоже кто во что горазд: есть как view-based подходы без фрагментов вообще, так и на фрагментах (Cicerore), так и самописные вещи (appkit от @grishka- клевая и понятная либа и подход на самом деле, мне понравился!), ну и конечно рекомендуемый Гуглом Navigation Component (не использовал, какой-то монстр).
Вы еще не устали? Это не конец, ребята.
Дальше где-то в альфе болтается и начинает всплывать Jetpack Compose UI библиотека и конечно же Гугл начинает депрекейтить свои предыдущие подходы и рекомендует теперь везде юзать классный-новый-молодежный Compose. В это время где-то на другом континенте уже разрабатываются KMM (Kotlin Multiplatform Mobile) - технология кроссплатформенной разработки, где общий слой данных пишется на Kotlin, а UI часть пишется нативно - для Android на Compose, для iOS - на SwiftUI.
Ребята (из Гугла), вам не кажется, что это: а) не уважение к разработчикам, которые должны выкинуть на помойку все свои "старые" знания и подходы, б) все становится как-то слишком сложно...
Вот простой чек лист, чтобы джуну написать "Hello, Android {UserName}", где UserName берется по сети из АПИ, сохраняется в БД и потом оттуда начитывается:
Возьмите Kotlin, Retrofit или OkHttp3 (для сети), Room (для БД), MVVM архитектуру, где - ViewModel - слой для хранения бизнес логики, UserRepository для данных юзера, Compose для UI, а если чего-то в нем нет, то Accompanist - библиотека-хелпер, в которой есть часто используемые штуки, которых нету в Compose. И я уверен, что это еще не конечный список :), вооружитесь нужными чатами, где вы сможете найти ответы, когда у вас что-то будет криво работать или, например, списки тормозить в Compose.
Я предвижу вопросы, что на компоуз теперь в 100 раз легче делать приложения. Но постойте, верстать - действительно легче, но хранить данные, передавать в UI часть, реализовывать бизнеслогику (ViewModel + Flow или mutableStateOf и др), взаимодействовать с Android или с кодом в обычных view - как будто сидишь на кактусе и вынужден все это писать...
Возможно проблема во мне, что я не до конца хорошо научился все это готовить.
А, я еще забыл про Flatter, который развивается параллельно и черт его знает, что в итоге выберет Гугл - Flatter или KMM + Compose. Вполне может что-то и похоронить.
Резюме:
Разработка под Android очень быстро меняется, Гугл постоянно депрекейтит "старые" подходы и библиотеки и разработчик должен либо следовать подходам гугла, чтобы иметь востребованные знания для большинства компаний, либо можно игнорировать их, но это видимо случай для проектов с большой историей или своих стартапов.
Разработчики под Android, поделитесь какие у вас мысли на этот счет.
JS Фронтэнд
С этим направлением работаю не так давно и пока только на Angular. Не застал перехода с AngularJS. В целом по ощущениям - это фреймворк корпоративного уровня, в котором есть все (или почти все из коробки). В отличие от того же React, который просто UI либа, а роутинг, хранение данных, реактивность - это функционал сторонних библиотек.
В самом фронтэнде конечно тоже тонна библиотек и подходов, но лидерами стали React/Vue/Angular. В Angular за год работы с ним я не увидел каких-то радикальных изменений, что не может ни радовать, - значит технология зрелая.
Резюме:
Да, веб фронтэнд тоже очень сильно менялся и меняется, но есть ощущение, что выделились лидеры: React, Vue, Angular. Можно взять какой-то из них у быть так сказать разработчиком под фреймворк. Для себя пока не решил до конца - интересен ли фронт и хотелось бы развиваться в нем. Можно ли будет потом переиспользовать этот опыт если опять произойдет какой-то сдвиг уже тут?
Бэкенд
В основном работал с Golang + немного посмотрел Spring Boot + Kotlin. Ну, чтобы начать что-то делать, достаточно: Golang, SQL, NoSQL базы данных и пожалуй все. Можно начать разработку сервиса с монолита, а до микросервисов может и не дойдет дело. Из баз данных достаточно поизучать реляционную PostgreSQL, нереляционные, например, документо-ориентированные (MongoDB), Redis или Memcahed для кеша. Что там еще осталось: очереди сообщений, управление кластером в kubernets.
На Golang писать просто, но есть и минусы, вытекающие из его простоты:
Много бойлерплейт кода: проверки на ошибки, мало абстракций, нельзя переопределять функции итд, простая стандартная библиотека, мало коллекций итд
Сложно (я бы сказал геморройно) писать бизнес-логику: взять для какого-нибудь клиента посчитать цену заказа, посчитать скидки, проверить его баланс, провести заказ итд - все это может вылиться в большие "простыни" кода. Подчеркнул здесь слово может, так как если аккуратно написать нужные структуры, интерфейсы к ним, вспомогательные методы работы с коллекциями объектов бизнес-логики, то может и норм будет.
Из коробки для работы с БД можно писать plain SQL запросы для работы с данными, что может потом стать большой проблемой, если будет масштабный рефакторинг кода. Есть конечно Gorm (Go ORM) библиотека и другие, но в своих проектах не использовал, не могу сказать. Подозреваю, могут возникнуть проблемы, когда надо получить данные из запроса с большим кол-вом JOIN разных таблиц - в ORM придется выгребать данные в виде коллекций объектов, потом в коде описывать логику из объединения итд, что приведет к бойлерплейту из п.1
Spring Boot + Kotlin. Почему Котлин? Потому что есть опыт разработки на Android, где Котлин. Почему бы и не попробовать его в бэкенде: хорошая стандартная библиотека, удобно работать с коллекциями, DSL (если надо) итд. Про Spring boot видимо нет смысла особо говорить - устоявшаяся технология в корпоративном мире.
В целом есть ощущение, что в бэкенде более устоявшийся стек технологий и подходов, все не так быстро меняется и свои знания можно прокачивать и не боятся, что они будут очень быстро устаревать.
К минусам по сравнению с мобилкой и фронтэндом я бы отнес, что вы где-то "сзади" крутите гайку и не видите напрямую результата - написали какой-нибудь эндпоинт или сервис, который просто отдает данные. А в мобилке - вы добавили какую то фичу в UI и сразу видите свой результат вживую.
Вместо заключения
Есть желание развиваться в какой-то технологии, где не устаревают знания очень быстро, чтобы был релевантный опыт, экспертиза и можно было претендовать на более высокие позиции по карьерной лестнице. Или это так не работает? :)
Пользуясь случаем, вопрос к аудитории - есть ли возможность карьерного роста в больших компаниях: Сбер, Озон, Авито, Яндекс, Банки и др. с позиции сеньор бека или сеньор фронта?
Очень важный вопрос по сравнению ЗП в мобилка/фронт/бекенд не изучал пока. Это отдельная тема, которой тоже надо озаботиться :)
