Comments 31
Товарищи, не стесняемся, активнее комментируем )
У меня все просто было. Первая работа - хоть как то в программирование вкатиться, так что 1с занимался. Потом когда опыта набрался - выбирал из бекенда и андроида. Веб фронт сразу отмел из нелюбви к js, ios по причине закрытости. В итоге выбрал андроид, больше из того принципа что я всегда любил идею носимых с собой компьютеров. Да и в целом интерес мой к айти и первые попытки программировать с нокии 5300 начались, а затем со смартов на симбиан (компа не было, зато телефоны были).
З.Ы. Сейчас по этой же причине начал о VR/MR/XR задумываться, но там все же пока слишком сыро все как по мне. Особенно если не игры брать, а именно приложения. Впрочем изучать там столько - что сейчас вообще не до этого, упор на языки иностранные делаю, может к тому моменту как время и возможность появится и экосистема улучшится.
Статья понравилась, хороший обзор технологий. Подскажите что почитать подробнее по архитектурам: про MVC, MVVM, MVP, flow и т.п. чтобы пришло понимание как что и где использовать?
По MVVM можно эту глянуть - https://habr.com/ru/articles/332562/ и https://developer.android.com/topic/libraries/architecture/viewmodel , по остальным архитектурам тоже на хабре можно поискать статьи.
MVVM использовал именно следуя гайдам гугла, где реактивные данные хранились в LiveData или Flow.
По поводу понимая что где использовать, к сожалению, нет универсального рецепта. Вы можете прийти в компанию, где уже готовый проект и там сформирована архитектура. А самому выбирать - это если ваш проект или стартап. И тут тоже есть ньюансы, если делаете MVP (Minimal Valubale Project), то достаточно MVC. А дальше станет понятно, надо ли что-то менять.
Привет, нахожусь на таком же распутье. Сейчас больше 4 лет разработчик React Native. Вакансий всё меньше, из-за всем известных событий. Распутье - Flutter, нативный Android или нативный Ios. По Flutter вакансий так же как и на RN. Вроде делал пару проектов на нём, но как-то не зашло после реактивщины RN. На Android или Ios вакансий больше, но чтобы свичнутся, в основном надо старые технологии учить, так как Compose или SwiftUI еще в зачаточном состоянии и многие еще не перешли и не собираются
На RN есть вакансии в крупных компаниях ?
Аналогичная ситуация и у меня.
Есть ли смысл дальше углубляться в RN?
Flutter с первого взгляда показался сложным. Или стоит его покапать?
А в крупных конторах Flutter юзают? Не получится потом что надо будет с фрилансерами конкурировать за хлеб на флаттере?
Я не против фриланса. Но лучше когда есть альтернатива на всякий случай.
По поводу Flatter vs RN vs KMM (Котлин мультиплатформ). Общался с менеджером из Яндекса по поводу карьерного пути (конферениця YaTalks была), говорит они в своем супеарре планириую KMM заюзать. Но там тоже ебли хватает, когда я его смотрел. Может крупняк и будет этот подход юзать, так как оно ближе к платформе и ползвотояет нормально заюзать многопоточность если надо
По поводу фриланса - да, основная масса работодателей или мелкие конторы, которые хотят быстро что-то выпустить и сэкономить. Или галеры, которые напели как будет дешево и быстро заказчикам ( что не всегда верно ).
Ну в Яндексе Flutter тоже юзают. Чел из команды такси выступает постоянно. KMM что-то пока эфимерно-мутно-странное. Основная масса проектов это получить json с бека и вывести пользователю. Получить что-то от пользователя и отдать беку :) И какую логику тут шарить между платформами ?
Я склоняюсь что RN и Flutter так и будут идти ноздря в ноздрю. KMM поиграются, но для основной массы он бесполезен. Проще два нативных написать
Я больше склоняюсь к изучению нативной части. При любом раскладе, она пригодится. Что в RN, что во Flutter, что в KMM
Я хоть и не обладаю таким богатым опытом как у вас (работаю только фронтом 6+ лет), но, так как меня всегда интересовал такой же вопрос из за интереса в ит в целом, и, соответсвенно в какой то момент меня кидало(мысленно) также из стороны в сторону, я все таки остановился на том, чтобы идти в глубь и быть не просто к примеру react разработчиком, а быть сейчас скажу громким словом фронтенд инженером, тоесть грубо говоря плевать на чем писать, главное решать проблемы бизнеса. В целом, как мне кажется это потихоньку дает свои плоды, потому как не в первом уже месте я как lead/senior front и соотвественно по зп всегда удается получать выше рынка.
Спасибо за размышления.
Сам нахожусь в похожей ситуации с похожим анамнезом.
Только разрабатываю сейчас в мало популярном стэке и продаю с 2006го.
Пока склоняюсь к Go, так как по ощущениям меня больше к бэку тянет все время, плюс смотрел вакансии по количеству и зарплате - тут одни из самых приятных.
Водители лошадей - довольно консервативная профессия. Тысячи лет ей и до сих пор требуются. Если не будете жадничать вполне на ней можете жизнь просидеть и даже развиваться и менять стек не потребуется. Может вам рассмотреть такой вариант?
А если хотите высокую зарплату, то надо развиваться в соответствии с новыми, современными потребностями рынка. С учётом технологической сингулярности, менять стек приходится все чаще.
А, я еще забыл про Flatter, который развивается параллельно и черт его
знает, что в итоге выберет Гугл - Flatter или KMM + Compose. Вполне
может что-то и похоронить.
Ну кстати про Flutter и KMM тут неоднозначно. Google очень активно поддерживает Flutter, а KMM все еще находится в активной разработке. Пока сложно сказать когда Google что то забросит может произойдет такое что появится другая технология которое похоронит все.
Работаю с Андроидом уже ~15 лет. Именно так выглядит мир Андроида. Складывается впетчатление, что с года 15-го, Гугл не знает точно какое направление выбрать и ведёт параллельно несколько направлений.
С BE опыт гораздо меньше. Spring Java. Знания полученные там остаются релевантными и через несколько лет. Spring Boot вообще супер штука. Построить микросервесы относительно просто (всё из коробки). Из изменяемых требований при найме это в основном связанно с базами данных.
Очень здравые рассуждения. Сам задаюсь подобным вопросом.
После всей тьмы технологий, использованных в проектах, написанных "в одно рыло", остановился на следующей комбинации:
фронт: kotlin/js + compose for html;
бэк: spring boot + kotlin + postgresql + hibernate или jdbc (по ситуации, иногда вместе);
андроид: kotlin + jetpack compose + mvi + room + hilt + пропустил много всякой мелочи
Исходя из своего опыта (но у меня только корпоративные заказчики и пользователи) - при наличии веб-версии - десктопная версия уже не нужна. Также повезло с тем, что этой группе заказчиков/пользователей не особо интересна ios-версия, иначе бы я зашился.
Поскольку времени не хватает поддерживать актуальность знаний по всему, решил попробовать поджать стек технологий - на андроид и фронт использовать мультиплатформенный компоуз. Посмотрим, что получится. Но "если слишком широко шагать - штаны рвутся". :(
То что начали появляться сравнительно быстро новые подходы - это очень не плохо, тот же KMM (теперь KMP) вполне интересный подход с реализацией логики на Kotlin. Удалось поработать с этим подходом - правда на iOS экраны не верстали )
А вот то, что условно сначала кодили под View, а теперь начинайте новые проекты с Compose - это странно, так как по сути предыдущие знания по верстке уже не особо пригодятся, ибо подход поменялся.
Для меня лично из плюсов Compose - это более менее удобные Preview и более простая работа по верстке «кастомных вьюшек».
Кастомных вьюшек при условии, что они представляют собой композицию вьюх. А если что-то нарисовать на canvas, то как понял +- одинаково по сложности
Если често не очень верю в KMP
Гугл может так же внезапно и flutter/dart прикрыть ("а, не получилось нифига!!!", как в анекдоте про художника-парикмахера), кладбище проектов у него безразмерное :/
И я пока не слышал о серверном Dart'e, и двуязычия в этом случае не избежать.
А вот DTO и логика на одном языке (котлине, имею в виду) в одном фуллстек-проекте - удобнейшая вещь.
Карьерный путь: Android мобилка, фронт или бэкенд?