Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Java Ukraine 2019: результати дослідження

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Перед новим роком я створив невеликий опитувальник для учасників групи зокрема та українських джавістів загалом. Розкинув по всіх джавішних групах у ФБ та лінкедіні. За кілька тижнів опитувальник заповнило близько 400 джавістів тож я вирішив підбити підсумки, проте ви все ще можете заповнити опитувальник і я оновлю результати за якийсь час.

Отож, насамперед, трохи даних про людей, які заповнили опитувальник. Як бачимо, більшість респондентів віком від 30 до 40 років, це дещо неочікуваний результат, оскільки вважається, що джуніори більш активні (зауважте, кількість респондентів віком до 25 років становить всього 20%). У коментарях навіть була така думка:

Не довіряйте результатам, більшість відповідей будуть давати активні молоді люди, які нещодавно почали працювати. А вони все що нижче 12 версії рахують не вартим уваги. Хоча мій досвід показує, що від появи 6-ї версії чогось такого не з’явилось без чого не було б можливо жити. Мій досвід більше 16-ти років Java розробки. Активна робота зі всім, що дотичне до Java. Дякую

71% респондентів — розробники ПЗ, можу також припустити судячи із зауважень, що 5.7% які не вказали позицію — це QA інженери, що пишуть автоматизовані тести.

Більшість — чоловіки, жінок ледь більше 7%.

Оскільки це львівська група джавістів, то очевидно, що більше половини вказали місцем роботи — Львів (підозрюю більшість побачила мій пост у нашій FB-групі), чверть з Києва, ну і жменька анкет зі всієї України. Сподіваюсь з часом географія розшириться.

Дещо неочікувано для мене, але більше половини мають петпроджекти.

Порівняно невелика кількість робить свій внесок в проекти з відкритим кодом.

Загалом опитувальник складався з кількох логічних блоків: питання щодо версій java та загалом про мови, які використовуються, питання щодо фреймворків і бібліотек, питання з інструментарію та питання про процес розробки. Деякі питання видаються схожими, проте різні формулювання дозволили вибудувати більш чітку картину. Також на багато питань можна вибрати одразу декілька відповідей — це зумовлено тим, що значна частина працює на кількох проектах одночасно і ще більше міняють проекти протягом року, тому було б важко вибрати лише одну правильну відповідь

Отож, лідером в комерційних проектах зі значним відривом є java8 хоч загалом на 11-ку за рік мігрувало досить багато, з власного досвіду знаю, що це не так і просто.

Якщо взяти до порівняння домашні проекти де оновити версію набагато легше то там картина зовсім інша хоча «вісімка» з невеликим відривом лідирує і там

Міграція на нові версії штука не проста, тому майже 44% взагалі ніколи не мігрують продакшин на нові версії і ще 31% думають щоразу, коли виходить нова версія, що ж робити (підозрюю, думи ці не прості).

Нові проекти, як правило, плануються на LTS-версіях і тільки кожен п’ятий готовий взяти найновішу версію навіть без довготривалої підтримки

Найпопулярнішим імплементаціями JDK є очікувано OpenJDK та OracleJDK, хоча підозрюю з часом частка Oracle буде скорочуватись

Для повноти картини я поцікавився, якими ще jvm та не jvm мовами послуговуються. Картина передбачувана — більше половини взагалі інших jvm мов не використовує, а з non-jvm лідирує js.

Оскільки я підозрювавав, що левова частка джавістів працює над веб-проектами,

то одним з важливих питань було, які вебфреймворки використовуються. На вибір було десяток великих і малих рішень

я б сказав, що Spring переміг всіх двічі 🙂

Всі ці спрінгові проекти зазвичай крутяться на томкеті

А томкети розгорнуті на хмарах або власних серверах

І основним постачальником цих клаудів є Амазон

Поертаючись до фреймворків — BigData, схоже, не настільки розповсюджена як можна було подумати — 72% не використовують жодного фреймворку, хоч з іншого боку — 28% це більше ніж кожен четвертий проект, в якому працюють з BigData...

Зі звичайними реляційними базами на відміну від BigData працюють майже всі і біля 60% з jpa загалом та hibernate зокрема, що в певній мірі підтверджує думку про аутсорс як «формошльопство».

Бази під хібером, в більшості, фрішні MySql та Postgre

Нереляційні бази теж широко вживані — лише третина не використовує nosql в своїх проектах, Mongo та Redis попереду

Ще одним дуже поширеним компонентом сучасного девелопменту є черги повідомлень, де доволі неочікувано для мене на першому місці кафка

У межах блоку питань я ще поцікавився, хто користується Lombok’ом і виявилось — майже всі... окей, не всі, але справді дуже багато (якщо хто знає — розкажіть, як воно вживається з хібернейтом)

Ну і звичайно, не міг забути про системи логування (знаю slf4j не є окремою системою логування, проте питань було вже й так багато, тож не хотілось додавати ще одне)

Отож старенький log4j переміг logback 🙁 Більшімть все ж таки користуються slf4j — молодці

І це було останнє питання з блоку про фреймворки та бібліотеки.

Інструментарій

Вічно холіварна тема Idea vs Eclipse, схоже, отримала свою остаточну відповідь, проте почнемо з простіших речей: отож — мейвен все ще лідер, хоча грейдл успішно відвойовує своє місце під сонцем.

Майже всі вже перейшли на гіт, свн — вмер

хтось користується гітлабом, хтось гітхабом і навіть бітбакет не відстає — однозначного лідера нема

Також приємно відзначити що >99% користується бодай якоюсь системою контролю версій

Використання СІ інструментів незначно поступається за цим показником. Що тут казати — пишаюсь 🙂

Найпоширенішим є Jenkins на другому місці — «Інше»

Ну і найцікавіше наостанок

Це було останнє запитання...

Не буду робити жодних висновків з опитування, але був би вдячний за ваші думки, ваші висновки та ваші поради щодо наступного опитувальника.

P. S. Опитувальник все ще можна заповнити.

P. P. S. Велике дякую всім, хто виділив свій час, щоб дати відповіді на питання, а особливо тим? хто писав коментарі та поради. Я дуже ціную вашу участь.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
якщо хто знає — розкажіть, як воно вживається з хібернейтом

Абсолютно нормально. Он с хибом даже и не пересекается. Когда дело доходит до хиба, геттеры/сеттеры/ноаргконструкторы «уже есть».

Раньше, в 8 версии, с ломбоком не умел дружить нетбинс. Но с 11 версии даже он с ним дружит, и даже больше того — без дополнительных действий типа «включите анотейшн процесинг и установите плагин» как в идее.

біля 60% з jpa загалом та hibernate зокрема, що в певній мірі підтверджує думку про аутсорс як "формошльопство"

Не вижу логики в этом утверждении.
JPA — по сути, единственный высокоуровневый стандарт работы с рсубд.
Работаю с реляционной базой == формошлеп? Где логика?

хібер класний для проектів з хорошим мапінгом між юайним відображенням, моделями бізнеслогіки та таблицями. Чим більше розходження тим більше зусиль на орм і тим більше native sql на хібері. Тобто або у вас багато юайних сутностей які крудом ганяються туди назад, або ви взяли неправильний інструмент і у вас в коді купа перегонів дто-ентіті і купа нейтів сіквела. Якось так. Хоча звичайно різні кейси бувають і орм обгрунтовано використовується в ловлатенсі, хайлоад та всяких бігдата проектах

Якось так

Ваши выводы ошибочны почти полностью.

хібер класний для проектів з хорошим мапінгом між юайним відображенням

JPA хорош для любых задач по работе с рсубд, при условии что у разрабочтика прямые руки. Во всех остальных случаях, т.е. в случае рукожопости, JPA исключительно плох. Но дело тут не в JPA.
В том числе, JPA отлично подходит для задач, которые вообще не имеют маппинга на юайное отображение.

тим більше зусиль на орм

Вы путаете разные вещи, теплое с мягким, вкусное с полезным.
JPA != only ORM.
Спецификация JPA позволяет эффективно работать с бд, вообще не объявив ни единой @Entity.

тим більше native sql на хібері

Нейтив скл не является ничем плохим, как и сам факт использования реляционной базы, например.
Но факт боязни нейтив скл в среде девулоперов — гораздо более точный показатель формошлеп-майнд-сета, чем факт использования JPA.

Тобто або у вас багато юайних сутностей

Использование реляционной БД + JPA на бекенде не ограничивается созданием круд-приложений с веб-мордой, внезапно. Есть и machine-to-machine сервисы, которым, внезапно! тоже надо работать с базой.
Выбор JPA диктуется только сложностью модели. Чем сложнее модель — тем правильнее будет выбор JPA вместо plain old JDBC.

або ви взяли неправильний інструмент

JPA является правильным инструментом, если у вас в качестве хранилища (возможно, одного из хранилищ) выступает реляционная база.
Все остальные инсинуации — это не более чем проекции личного опыта написания только крудов, или же работы в компаниях, где ничего кроме круда-с-веб-мордой не пишут, а не свойства JPA как инструмента.

орм обгрунтовано використовується в ловлатенсі, хайлоад та всяких бігдата проектах

Если нужен очень ловлатенси и очень хайлоад, то как раз JPA является не оптимальным выбором, поскольку выполняет множество операций, не связанных непосредственно с запросил-загрузил-отдал.

Если нужен очень ловлатенси и очень хайлоад, то как раз JPA является не оптимальным выбором, поскольку выполняет множество операций, не связанных непосредственно с запросил-загрузил-отдал.

саме це я мав на увазі :) орм для складних кейсів не оптимальна, але цілком ок для форм чи рест апішки яка однозначно відповідає сутностям бази. Якщо писати більшість нейтів кверями чи тим більше не оголошувати ентітів тоді краще зразу взяти jdbc

Підписатись на коментарі