Размышляете, куда податься, какое карьерное направление будет перспективнее? Дело ведь не только в используемых технологиях, но и в распространенных подходах и практиках. И объективное сравнение от того, кто видел разные сегменты лично, встретишь не часто.
В этой статье наш коллега делится своими впечатлениями о том, чем отличается разработка бэкенда от мобилок на примере Android.
Всем привет! Меня зовут Юра. За 20 лет в статусе разработчика я успел посмотреть на этот мир и со стороны мобилок (Android, если быть точным), и со стороны бэкенда. На мой взгляд, подходы там отличаются, хотя и не так сильно, как можно было бы ожидать. Со временем процессы и паттерны кочуют из сегмента в сегмент, часто доказывая, что новое — это хорошо забытое старое. В этой статье хочу поделиться некоторыми наблюдениями, которые я сформулировал для себя, пока моя карьера совершала все эти маневры.
Предыстория
Мой карьерный путь — дело случая.
Я в ИТ года с 2002-го. На тот момент я еще учился в Институте, но параллельно работал в конторе с эдакими инженерами-схемотехниками лет по 40-50, разрабатывая на Delphi. Надо сказать, я там продержался довольно долго — молодые коллеги приходили и уходили, а я продолжал вариться в собственном соку.
На первом месте я отработал восемь лет. На волне развития смартфонов стал мобильным разработчиком — начал писать под Android. А спустя еще пять лет меня позвали в проект на бэкенд. Откровенно говоря, бэкендом я на тот момент не занимался, поэтому вряд ли меня взяли, если бы у компании не было планов на мобильное приложение в какой-то отдаленной перспективе. Но так сложилось, что два года я трудился в бэкенд-команде и был очень рад этому опыту. Возможно, и дальше бы остался на этом же поприще, но проект закрыли.
Я нашел другую работу — тоже на бэкенде. И в какой-то момент новый работодатель тоже пришел к мобильному приложению, так что я снова вернулся в Android. И следующая работа была опять чисто с мобилками. До этого все предыдущие работодатели были локальными, а тут мне предложили попробовать себя в крупном банке. Им я больше подошел в качестве мобильного разработчика. Впоследствии я попал в Максилект — также на проект с Android.
Хотя тут прослеживается определенный трек, в чистом виде на бэкенде или в Android я давно не работал — все время получалось какое-то совмещение. Пишешь мобильное приложение, но заглядываешь в API на бэкенде. Или работаешь на бэкенде, но имеешь в виду мобильное приложение. Так что я имел возможность сравнивать и анализировать, подмечать моменты которые мне нравятся или, наоборот, не нравятся в каждом из миров.
Бэкенд более спокоен в плане технологий…
В мире Android все очень быстро меняется. За пару лет технология становится неактуальной. Например два-три года назад все сидели на реактивщине, а сейчас наоборот, ее активно выпиливают из своих проектов, ведь теперь есть корутины для Kotlin. И так было всегда.
Именно эта скорость устаревания знаний и заставила меня в свое время посмотреть на бэкенд. В 2016 году я работал на специфическом проекте с легаси. Когда начал искать новую работу, понимал, что вроде бы опыт в Android-разработке большой, но устаревший. Актуализация знаний под Android и переход в бэкенд (где у меня не было опыта работы на проектах) требовали примерно одинаковых усилий. И лично мне оказалось проще изучить новую для себя сферу. Возможно, вопрос в закостенелости. Я уже привык под Android писать определенным образом. Когда ты отстал на два года и пытаешься это наверстать, выясняется, что привычные паттерны использовать уже нельзя, а перестроиться тяжело. Когда берешься за что-то новое, что еще никогда не делал, у тебя еще нет таких сдерживающих стереотипов.
А возвращался я в Android благодаря случаю. Как уже говорил выше, мой работодатель задумался о мобильном приложении, нанял аутсорсера, но впоследствии забрал у него разработку и передал мне. Так я получил в качестве старта уже готовое мобильное приложение, написанное на современных технологиях. Пришлось быстро вникать как будто с нуля, и здесь привычные паттерны уже не мешали.
С бэкендом ситуация иная. Ты можешь два года отработать на проекте, потом перейти в другой проект, где те же привычные технологии все еще будут актуальны. Основные вещи, необходимые для работы, примерно одинаковы. Ты легко можешь влиться, более того у тебя есть время стать экспертом высокого уровня в узкой области и это востребовано — на бэкенде очень тонко настраивается та же безопасность, есть тонкости с хайлоадом и т.п.
… но есть проблема обратной совместимости
Бэкенд требует более щепетильной работы с обратной совместимостью. Половина клиентов может просто не обновиться, и у них будут проблемы.
На смартфонах Google проделал большую работу, создав библиотеки compatibility. Если не ошибаюсь, после четвертого Android API для взаимодействия с системой один и тот же, вне зависимости от того, под какую версию ты пишешь (Google сам реализует необходимый вариант подкапотной реализации). Какие-то отличия в деталях, конечно, есть. Каждую версию что-то новое появляется, что-то по-разному настраивается — выходит новая версия и ты ожидаешь определенную головную боль. Но все это не критично. Тем более Google дает время на интеграцию обратной совместимости с учетом этих нововведений. Компилируя приложение, ты некоторое время после выхода новой версии ОС еще можешь указывать в качестве целевой старый Android. Только через полгода-год Google начинает требовать поддержки новой версии.
В Android есть определенная проблема с производителями устройств, которые по-своему реализуют внутренние системные сервисы. Этим особенно любит грешить Xiaomi и Samsung, причем либо на самых дорогих, либо на самых дешевых устройствах. Но в целом это известная проблема и она тоже решается.
А с бэкендом обратная совместимость требует внимательности. Надо быть аккуратным с контрактами — когда у тебя по контракту возвращается определенная сущность, то ее ты и должен возвращать. Плюс внимательно смотреть на опциональность параметров. При необходимости делать версионность и поддерживать несколько версий одновременно.
По первому впечатлению бэкенд — это команда со всеми вытекающими. Но не все так просто
Мой субъективный опыт говорит о том, что работа на бэкенде — штука командная.
Под Android я разрабатывал один — писал и UI, и бизнес-логику (по факту там и нет такого уж жесткого разделения), ковырялся в API со стороны бэкенда. Я мог писать так, как мне удобно, не надо было ни с кем ни о чем договариваться. Даже если в организации нас оказывалось несколько человек, разрабатывающих под мобилки, все писали порознь и с каждого спрашивали только конечный результат.
Перейдя на бэкенд, я оказался в команде человек на 10. И все они пилили один сервис. Для меня это был вау-эффект. Мне нравились сами процессы — ни разу не пожалел, что отказался тогда от мобильной разработки, даже несмотря на сокращение дохода. В команде ты не только пишешь и разбираешься с задачами, но также смотришь, что пишут другие, набираешься таким образом опыта.
Забавно, что сейчас с внедрением повсеместно микросервисной архитектуры тесно взаимодействующие между собой команды на бэкенде сокращаются. Раньше у тебя был монолит, отвечающий на все запросы, которые только возможно (оплата, корзина, клиенты). Это немного влияло на время сборки, но в целом решение было полностью функционально. И ты видел огромную команду, которая его пилит. Понятно, что каждый разработчик отвечал за какую-то свою задачу, но монолит на всех был один, а значит большая команда регулярно встречалась, чтобы синхронизироваться.
В микросервисах куски логики небольшие. Это плюс с точки зрения разработки и поддержки — например, его можно полностью покрыть тестами. Но всего рабочего процесса из одного микросервиса не видно. Каждый сервис пилит один или несколько человек — они его прекрасно знают и отвечают за него, но только за него. Получается, что бэкенд идет к небольшим группам с минимальным взаимодействием, касающимся скорее общих практик разработки, нежели конкретных проблем (типа а не перейти ли нам на Java 21).
В то же время Android-приложения становятся огромны. В одном инструменте может быть собрана масса сервисов, в итоге это приложение очень напоминает монолиты бэкенда из прошлого. И разработка варится в общей куче — каждый сам по себе уже не независимый. Да, и на Android уже начали выносить часть бизнес-логики в отдельные модули, чтобы ускорить время сборки и облегчить их поддержку. Так что в каком-то смысле все идет по кругу.
На бэкенде проще дебажить и выкатывать исправления
Наверняка у каждого, кто разрабатывал для мобилок, была ситуация, когда приложение уже выкатили на пользователей, но потом выяснилось, что в нем ошибка, которая воспроизводится не у всех. И ты начинаешь ломать голову — по стек-трейсу ничего непонятно, логи у пользователей надо собирать отдельно и подумать о них заранее (внедрять кнопки для пользователей, которые будут разрешать отправку логов).
На бэкенде все гораздо проще. Можно все приложение обставить логами, дождаться, пока на клиенте проблема повторится и по логам посмотреть, что произошло.
А главное, когда исправления внесены, на бэкенде можно все это раскатить гораздо быстрее. Ты просто пересобираешь приложение и перезапускаешь затронутые микросервисы. На Android ты заливаешь приложение в магазин и несколько дней ждешь, пока пройдет ревью.
А на Android сложнее упереться в высокие нагрузки
На Android почти не бывает сверхнагрузок. Возможно, ты столкнешься со сложным кейсом с кучей экранов, каким-то нетривиальным UI, но логика приложений обычно довольно простая.
Безусловно, на бэкенде полно задач, не связанных с высокими нагрузками. Такой была моя первая работа — агрегатор авторемонта. Но вторая работа была уже сложнее — нужно было пилить сервис для телевизоров на голом Android (не Android TV), в котором не было Google Play, поскольку китайцы не планировали отчислять в Google деньги. И этот сервис был уже нагруженным.
Когда у тебя нет опыта, ты не знаешь, с какой стороны подойти к решению задачи: у тебя десятки тысяч запросов в секунду и ты должен на каждый ответить достаточно быстро. Что-то в сервисе надо переделывать, но что…
С Android-ом не заскучаешь
Выше я говорил, что мир бэкенда — более спокойный. Прямое следствие этого — тебе могут надоедать одни и те же технологии на разных проектах, примененные в более-менее схожих задачах. Запрос от клиента пришел, ты что-то в базу положил, где-то посчитал, вернул ответ.
С той скоростью обновления технологий, которую мы видим на Android, так скучать времени просто не будет.
Вместо итогов: расширять кругозор полезно
Я нисколько не жалею о своем опыте — ни о переключении на бэкенд с потерей зарплаты, ни о возвращении на Android. Здорово, когда разные проекты позволяют расширять кругозор. Пробуешь один профиль, другой, третий… Все это — опыт. Даже если он никак напрямую не пригождается, у тебя появляются новые точки зрения, другой взгляд на мир.
Когда ты сидишь простым Android-разработчиком, тебя не волнует как реализуют необходимую тебе логику на бэкенде. У тебя есть запросы, тебе просто нужны ответы.
А когда ты поварился на той стороне кухни, уже немного по-другому смотришь на то, как поставить задачу — нужно ли тебе определенное поле в ответе? (ведь у ребят на бэкенде все будет намного сложнее) Или здесь можно что-то сделать проще?
Ну и разносторонний опыт — это банальный плюс для резюме.