Долго читаю, но на волне взаимопомощи решил зарегистрироваться. Работаю java разработчиком, могу помочь разъяснить какую-нибудь тему или помочь понять куда двигаться по обучению, поревьюить код или просто как-то пообщаться вживую если потребуется
Поработал на java, но почти чистой. Куда развиваться? Насколько востребованны фреймворки?
Фреймворки крайне востребованны, плейн джава никому не нужна. Здесь есть 2 наиболее востребованных направления - переход под андройд или в энтерпрайз. Второе наиболее востребовано именно с точки знания java (слышал в современных андройдах достаточно обойти JS-ом)
В энтерпрайзе можно пойти в автотестирование и изучать паттерны (Method object), селениум и прилагающие вещи а можно пойти в разработку.
Если вы пойдете в разработку, то, скорей всего вам понадобится изучить стандартный стек. Вот примерный план:
Web:
-Изучите http протокол и основы rest архитектуры.
-Получите основное понимание контейнера сервлетов
-Определитесь с изучаемым стеком: java EE или spring
DB:
-SQL (на уровне написания запросов с использование join-ов и применением агрегирующих функций)
-Jdbc (на уровне как открыть коннекшен)
-JPA (hibernate) - понимание когда открыт персистент контекст и какие запросы выполняются при использовании критерии/hql. Понимание типов связей и.т.п.
Если выбрали spring как основную платформу - нужно понимать как работает IoT и dependency injection и как разворачивается контекст
Но вообще оно все корректируется в зависимости от желаний/потребностей на рынке. Соответственно и план обучения может изменяться (некоторые проекты работают только в микросервисах и без JPA, или вообще только на нереляционных базах данных)
Android процентов на 90 на котлине, на java там легаси в основном. Касаемо бека, там наоборот, kotlin'a мало очень.
Есть одна компания - российский Алиэкспресс, в которой бэк частично на Котлин. Вполне себе энтерпрайз
Есть довольно много стартапов которые переходят на котлин. Вообще - модно, удобно, молодежно - но старые мастодонты с долгосрочными проектами боятся его трогать, предпочитая груви альтернативой, т.к. на груви можно соблюдать все java-инструкции, а на котлине придется немного адаптироваться под синтаксис языка.
Вообще на котлине писать приятней и удобней, но проекты на нем существенно новей и, обычно, требуют дополнительных знаний помимо основного стека
Что-то вэб лист спорный. Полезно ли учить протоколы и стандарты без практики (бы запихнул этот пункт после spring даже)?! Можно ли получить понимание того что такое и как работает контейнер сервлетов без самих сервлетов (уже придётся потрогать java ee)?! А если выбрать spring то неужели можно обойтись без базового понимания java ee (Spring ведь имеет кое-какую родственную связь с java ee, не так ли)?!
в общем я бы предложил другую модель:
Web:
- Посмотреть что такое сервлеты и попробовать собрать какой-нибудь сервер на них с любым контейнером и в процессе посмотреть инфу что же такое контейнер и как оно работает (естественно после создания чего-то что смогло задеплоиться нужно протестить это запросами)
- Понять что есть масса непонятных моментов и попробовать найти ответы на все появившиеся вопросы (можно переписать пункт как "изучение java ee и http")
в идеале после этих двух должно быть чёткое понимание того что такое контейнер сервлетов и как оно работает, а так же понимание того как обрабатывается запрос, отправленный с клиентской части ну и должно появиться понимание того что есть какие-то там http методы и есть разница между GET и POST
- как только есть понимание как работает то что создавалось выше можно доставать spring и делать то же самое но уже используя этот фрэймворк (идеально было бы ещё разбираться а как оно работает под капотом)
Почему в моей версии нет выбора между java EE и spring? Хороший вопрос) Едва ли будет хоть одно собеседование на любую позицию/проект где не спросят про spring, а программирование учат чтоб успешно устроиться на работу, правда?!
ближе к концу коммента понял что и DB можно покритиковать но что-то лень уже(
ох, да и "нужно понимать как работает IoT" или ".. IoC"?
План был примерный как направление в котором нужно копать :) По поводу критики:
Http мастхев к изучению. Не могу представить как можно писать веб сервисы принимающие запросы, не понимая из чего состоит сам запрос. Если вы пишете @RequestMapping не понимая что в загаловке/теле метода, да и вообще - не понимая как отправить запрос на сервер - вам все равно придется изучить http, только в этом случае вам придется изучать 2 темы параллельно, получая кашу в голове. Даже при написании сервлета нужно будет разбираться в чем различие между doGet и doPost.
Мне кажется ваши пункты:
Можно ли получить понимание того что такое и как работает контейнер сервлетов без самих сервлетов (уже придётся потрогать java ee)?!
и
- Посмотреть что такое сервлеты и попробовать собрать какой-нибудь сервер на них с любым контейнером и в процессе посмотреть инфу что же такое контейнер и как оно работает (естественно после создания чего-то что смогло задеплоиться нужно протестить это запросами)
немного противоречат друг другу. Разумеется контейнер придется запустить разок и чтобы он работал придется написать хотя бы один сервлет чтобы понять устройство работы.
Не совсем понимаю взаимосвязь конейнер сервлетов = java ee. Java EE это гигантский набор спецификаций, и работа с сервлетами лишь крайне малая ее часть. Вы ведь прекрасно понимаете что если вы выбираете спринг как платформу - вы все равно регистрируете DispatcherServlet внутри контейнера сервлета, после чего он уже переопределяет логику и это понимание крайне важно - спринг не изобретает альтернативу сервлетам, а просто навешивает дополнительную абстракцию используя тот же самый механизм что был в предыдущей теме. Вы ведь не будете говорить что весь спринг это java EE?
Ваш же подход сводится к "попробуй, у тебя не получится вот и изучишь предыдущие темы на практике", что имеет право жить, но в долгосрочной перспективе (на мой взгляд) может не позволить адекватно сегрегировать полученные знания.
Касательно java ee - зря вы так. Спринг развивался как альтернатива устаревшим спецификациям, но в последние 5 лет EE модернизируется и позволяет некоторые вещи делать удобней чем в том же спринге. Да ~80% рынка на спринге, но вакансии есть и без него.
P.S. да, IoC, опечатка
Зашёл в топик исключительно чтобы посмотреть срачики) обычно такие темы никогда без них не обходятся)
Да не все так плохо там, просто вас пугают рассказами про кучи xml конфигураций из 2010х годов :)
Честно говоря - хз. Oracle владеющей java ушел из России, но, думаю, форкнуть или использовать альтернативную jdk никто не запретит.
Поправлю коллегу: касаемо андроида сейчас уже в основном kotlin, java если и есть, то только в легаси. Чего-то новое делают в 99% сразу на котлине.
Помощники
236 постов785 подписчиков
Правила сообщества
Нельзя обсуждать Политику.
Ругаться и оскорблять.