Бэкенд или мобилка. Что выбрать?

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Привет! Этот пост - ответ на статью Направо пойдешь — в бэкенд придешь, налево — в мобилки. У меня похожий опыт, я более 5 лет работал fullstack-разработчиком, затем с 2015 года перешел в Android. Я пришел к другим заключениям, чем автор и хочу поделиться своей точкой зрения по вопросу "где лучше живется в бэке или мобилках".

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

Немного о моем опыте

Я начал работать Java Enterprise разработчиком в 2008 году будучи студентом, работал в качестве fullstack разработчика. С Android познакомился при обучении в LUT в 2010 году, это был интересный опыт, подробнее написал об этом пост в своем канале. Далее с 2010 года по конец 2014 работал с Java Enterprise, при случае переключаясь в Android, куда с 2015 года полностью и перешел. За это время у меня было большое количество проектов как с fullstack, так и с Android, ниже попробую дать небольшое сравнение.

Команда и процессы

Здесь хотел бы развеять миф о том, что разрабатывать под Android значит обязательно заниматься этим одному. Можно привести пример популярных сервисов или банковских приложений, в которых над одним приложением могут трудиться 50-100 разработчиков, поделенные на команды. Целая команда может заниматься одним экраном приложения, например, экраном авторизации. При этом существуют отдельная команда, которая занимается сборкой.

Бывают ситуации, когда над приложением работает один разработчик, наиболее частые кейсы:

  • прототип приложения

  • фриланс

  • инди/пет проект

  • старт проекта, когда приглашается разработчик, которому предстоит набрать команду

В "среднем по больнице" для разработки мобильного приложения собирается команда, хотя бы потому что силами одного разработчика фичи будут поставляться очень медленно. На моем опыте был всего один раз, когда я был единственным in-house Android-разработчиком, но это был как раз тот случай, когда дальше подбиралась команда проекта. Как правило процессы разработки схожи с бэком, обычно за основу берется что-то из Agile (Scrum, Kanban, Scrumban и т.п).

Поиск багов и выкатка новых версий

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

Раскатывать новые версии на бэке действительно проще, фичи быстрее доставляются клиенту. С другой стороны мобильные приложения многих сервисов все чаще используют подход BDUI, который позволяет сократить time-to-market и сделать его примерно равным бэку.

Количество логики и сложность проекта

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

Конечно, есть определенная специфика для каждой специализации. Например, в бэке намного больше работаешь с базами данных, структура БД в разы более сложная. Также часто бывает много интеграций с различными системами, получение и передача данных и т.п. В мобилках с другой стороны очень много работы с многопоточкой, оптимизации UI/UX, адаптации под разные устройства. И там и там как правило уделяется большое внимание архитектуре, возможностям масштабирования и тестирования.

IT - постоянное развитие технологий

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

Что же выбрать?

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

Источник: https://habr.com/ru/articles/793842/


Интересные статьи

Интересные статьи

Размышляете, куда податься, какое карьерное направление будет перспективнее? Дело ведь не только в используемых технологиях, но и в распространенных подходах и практиках. И объективное сравнение от то...
Привет, Хабр! Мы много разговариваем про найм, и решили запустить новую рубрику — разбор резюме. В ней наши профессиональные HR, которые регулярно просматривают сотни резюме, будут смотреть на прислан...
Думаю, лишь малая часть людей поспорит с тем, что 2020 год разделил рынок труда на "до" и "после", перенося просто огромную часть жизни в интернет-пространство. Всего несколько месяцев жесткого локдау...
Привет, Хабр! Сегодня хотим обсудить «вечную» тему нынешнего века – эффективное и надёжное хранение данных. По исследованиям некоторых учёных, в год человечество генерирует данных больше, чем вся циви...
Как изменить архитектуру монолитного продукта, чтобы ускорить его развитие, и как поделить одну команду на несколько, сохранив согласованность работы? Для нас ответом на эти вопросы стало созда...