Что и почему используют Java-разработчики: опрос RebelLabs

Ранее мы уже упоминали результаты опроса от RebelLabs (онлайн-версия, PDF-версия), в котором Java-разработчиков расспросили «что вы используете» (от IDE до архитектуры), «почему именно это», «довольны ли» и «если недовольны, почему не меняете».

А теперь мы решили, что этот подробнейший и интересный текст заслуживает перевода на русский, и сделали его для вас. С публикации оригинала прошло уже два месяца (стоящую за RebelLabs компанию ZeroTurnaround за это время даже успели купить), но мир Java-инструментов меняется очень неторопливо, так что текст по-прежнему актуален. Получилось так монументально, что сделали даже оглавление:

• Вступление
• Данные
• О респондентах
• Какие инструменты вы используете?
• Вам нравятся инструменты, которые вы выбрали?
• Почему вы используете инструменты, которые используете?
• Просто ли изменить сделанный выбор?
• Являются ли DevOps и производительность просто словами?
• Мир в огне, или у нас есть шанс?
• Увлекательные мелочи
• TL;DR и ключевые выводы
• Резюме и комикс напоследок

Добро пожаловать в «Отчёт о продуктивности разработчиков 2017» от RebelLabs!

Это аналитический отчёт, основанный на онлайн-опросе Java-разработчиков и целых команд. Отчет посвящён инструментам, их популярности и причинам использования. В отчёте за этот год мы сосредоточились на том, почему джависты используют те или иные инструменты и насколько они удовлетворены своим выбором.

Java-инструменты и технологии в 2017-м

В RebelLabs мы создаем отчёты на основе опросов в течение уже шести лет. Одна из основных причин для этого — желание понять, как развивается сообщество разработчиков Java, какие инструменты они используют, и каковы текущие тенденции.

Поскольку речь идёт о Java, понятно, что всё движется далеко не со скоростью света, и в выборе инструментов за год не произойдёт существенных изменений. Вот почему мы делаем такой отчёт раз в два года. А в «промежуточные» годы мы задаём вопросы о чём-то более конкретном. Например, о проблемах с производительностью и способах их решения, о продуктивности или о инструментах командной связи. В этом году мы решили копнуть глубже и спросить о причинах выбора инструментов.

Чтобы получить данные, мы каждый год проводим публичный опрос в RebelLabs, а также просим всех, кого мы знаем, пройти его, и поделиться им со своими контактами. Так мы пытаемся получить как можно больше данных, чтобы результаты стали как можно более полными. И да, мы знаем, что это не самый научный метод для выбора анкетируемых.

Действительно, мы в первую очередь опрашиваем клиентов ZeroTurnaround и тех разработчиков, с которыми нас разделяет минимум рукопожатий. Но это лучшее, что можно сделать в этой ситуации. Мы не утверждаем, что результаты представляют всё сообщество. Конечно, в нашем случае есть разработчики, команды и проекты, которые отличаются от типичного респондента. Тем не менее, мы склонны верить (и результаты из года в год на это указывают), что данные, которые мы получаем, имеют ценность, представляя Java-сообщество и типичных Java-разработчиков в существенной степени.

Данные

Данные для этого отчёта взяты из результатов публичного опроса RebelLabs, который мы провели в мае-июле 2017 года. Мы получили около 2060 ответов.

В этом году отчёт концентрируется на причинах, по которым разработчики используют те или иные инструменты. Мы рассмотрели использование IDE, основных языков программирования, основных вариантов стека приложений, архитектуры и выбора баз данных. В каждой категории мы задавали следующие вопросы:

• Что является вашим главным X? В этом случае X могло обозначать IDE, язык программирования и т. д.
• Какова основная причина, по которой вы используете X?
• Насколько вы удовлетворены своим выбором X. Оцените его по шкале от 1 до 10.
• Если удовлетворённость составляет 5 или менее, какая основная причина мешает вам перейти к другому выбору?

Мы проводили опрос с помощью Typeform, и данные были загружены в базу данных. В этом году мы предоставили данные публично. Если вас интересуют какие-либо выводы, не описанные в этом отчёте, просто клонируйте репозиторий, поиграйте с SQL-запросами и смело публикуйте любые найденные факты и закономерности, которые вам покажутся интересными.

Чтобы сделать отчёт легче для восприятия, графики в этой статье создаются без учёта выбросов. Для краткости мы решили, что любой ответ, набравший менее 1%, может быть выброшен. То есть, все ответы, которые были выбраны менее 20 опрошенными, мы выбросили. Это устраняет излишнее разнообразие вариантов (простите, пользователи emacs), но не меняет общую картину.

О респондентах

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

В этом году мы впервые спросили, в какой стране работают наши респонденты. Это был факультативный вопрос. Любой, кто не мог найти подходящий ответ (например, работает из Европы на американскую компанию) или не хотел делиться своим местоположением, мог просто не отвечать.

Наиболее популярными странами в опросе были: США — около 15%, Германия — 8%, Соединенное Королевство — 6%, а также Индия и Бразилия — по 5%. В целом, мы получили ответы от 103 стран по всему миру.

Теперь давайте посмотрим на распределение респондентов по должностям. Мы предложили такой набор вариантов, в котором все software engineers и Java developers оказывались объединены в один пункт «разработчик программного обеспечения». И они составили большинство респондентов (около 54%). Архитекторы и руководители команд представляли собой 18% и 17% соответственно, при этом в опросе также присутствовали консультанты (4%), менеджмент (2%), высшее руководство (2%) и developer advocate (3%).

Присутствие такого количества людей из developer relations удивило нас, но, вероятно, это часть их работы — участвовать в движухе сообщества. В любом случае, абсолютное большинство респондентов — это технические специалисты. Таким образом, мы получаем данные от людей, которые живут и дышат кодом каждый день.

Теперь давайте посмотрим на размеры команд, в которых работают разработчики. Размер команды, безусловно, влияет на выбор инструментов. Было бы разумно предположить, что чем больше команда, тем больше времени уходит на общение, встречи и другие управленческие накладные расходы. Одно дело — одиночный хакер, редактирующий файлы классов непосредственно в vim, и совсем другое — команда из нескольких десятков разработчиков. Конечно, это требует другого подхода к процессу разработки.

В целом компании следуют принципу «команду можно накормить двумя пиццами»: самый популярный размер команды, для почти половины опрошенных, составляет от 3 до 9 человек. У 22% немного больший размер команды, от 10 до 19, а прочие варианты составляют менее 10% каждый.

Еще один вопрос, помогающий составить представление о респондентах, касался опыта работы. Как вы можете видеть, у большинства респондентов от 6 до 15 лет опыта. Удивительно мало оказалось менее опытных разработчиков. Менее 2 лет у 5%, а 5-10 лет у 14%. Получается, только у одного из пяти менее шести лет опыта. Стоит учитывать, что тут от человека требовалось оценить самого себя с точностью до года.

Мы затем сгруппировали ответы. Люди склонны округлять сроки, поэтому 10 лет получили 12% ответов, а 20 лет — 8%. Числа вокруг них были менее популярны: 9 и 11 набрали по 3%, у 19 и 21 — около 1%.

Впрочем, этому распределению можно поверить, если вспомнить, что Java уже 20 лет: если кто-то занялся разработкой в начале нулевых, у этого человека будет около 13 лет опыта.

Мы почти закончили с общими вопросами. Последнее, что нам нужно, чтобы лучше понять разработчиков, это узнать в каких компаниях они работают. Слепить minimum viable product в гараже друга даёт больше свободы, чем работа с государственными контрактами в компании из списка Fortune 500 (где босс никогда не рискует быть уволенным за выбор решения IBM).

В прошлых отчётах об экосистеме Java мы включили вопрос о том, какой тип приложений они разрабатывают: веб-приложения, библиотеки и т. д. Однако в этом году он был заменен на вопрос о том, какой стек приложений используется их основным проектом. Очень вероятно, что если они используют Spring Framework или Java EE, проект является веб-приложением. То же характерно для других стеков. Поэтому мы просто не стали включать этот вопрос дважды.

Какие инструменты вы используете?

Ура! Вы попали в основную часть отчёта! Давайте будем честными, в любом отчёте RebelLabs интереснее всего узнавать об инструментах, используемых командами по всему миру. Нам всем нравится сравнивать себя с другими, искать подтверждения для нашего выбора, а если мы недовольны тем, что используем сейчас — искать, чем люди довольны больше.

Начнём с главного для любого разработчика. Того, на что смотрят весь день; самого ценного и личного инструмента, навыки работы с которым оттачивают на протяжении многих лет; того, что разработчики очень любят любить: IDE. Кстати, по нашим данным, противоположностью — самыми ненавистными — являются инструменты сборки. Их не любит никто.

Есть три ведущих Java IDE. Все три относительно хорошо представлены в отчёте. IntelliJ IDEA захватила уже аж 54%, что делает её явным лидером. Каждый третий разработчик использует Eclipse IDE (33%), а 13% заявили, что используют NetBeans.

Поскольку это не первый отчёт, в котором мы спрашиваем об используемой IDE, и количество респондентов раньше было примерно тем же, можно построить график изменения доли рынка за последние несколько лет.

Как вы можете видеть, IntelliJ IDEA продолжает набирать аудиторию, получив теперь более половины голосов респондентов. Будет интересно посмотреть, будет ли она продолжать завоёвывать популярность в ближайшие годы.

Теперь давайте посмотрим на популярность языка программирования. Как и в предыдущих докладах, мы задали вопрос о главном языке программирования для вашего основного проекта. Даже если вы используете несколько языков в нескольких проектах, вам нужно выбрать тот, который для вас наиболее важен.

Неудивительно, что Java 8 является лидером этой языковой гонки, набрав 72% всех голосов. Java 7 и старше — это следующий наиболее популярный ответ, что также неудивительно, поскольку многие основные проекты часто бывают довольно старыми. Но нельзя игнорировать, что публичные апдейты для Java 7 прекратились ещё в июле 2015 года! Что это значит? Может быть, пришло время для обновления? Может быть, даже попробовать Java 9, которая вызревала более 7 лет? Уж после такого-то она должна быть хорошей, не так ли?

Альтернативные JVM-языки, как обычно, присутствуют, но их общая доля падает ниже 10%. Новичок в нашем отчёте, Kotlin, попав в общепринятое семейство языков JVM, дебютирует на уровне 1%.

Затем мы спросили о стеке приложений для ваших основных проектов. Этот вопрос в какой-то степени заменил вопрос о том, какие типы приложений вы разрабатываете. Это интересный вопрос. Он говорит не о веб-фреймворках, а скорее о том, что является самым важным компонентом вашего стека приложений, основывая всю систему.

Как бы то ни было, победителем является Spring-стек (известный в первую очередь по Spring Framework, а это как раз веб-фреймворк), набравший 46% голосов. Да, почти половина разработчиков основывают свой код на Spring. Примерно каждый третий голосовал за Java EE (33%). Около 8% работают без каких-либо названных нами стеков. Обратите внимание, что при всей шумихе вокруг микросервисов и легковесных фреймворков, помогающих в их создании, в реальности они не очень-то популярны. Нечасто используются и реактивные подходы к созданию приложений: только 3% респондентов говорят, что их основные проекты являются реактивными.

Но есть интересный факт. В Spring 5 уже включен реактивный веб-фреймворк. В следующем году мы можем увидеть более широкое принятие идей реактивного программирования, если эти 46% Spring-проектов начнут использовать новые возможности.

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

Не слишком удивительно, что разделённая архитектура занимает первое место в этом списке с 34%. Этот выбор архитектуры был популярен среди всех разновидностей Single Page Apps и обширной экосистемы JavaScript-фреймворков. Также стоит отметить, что микросервисная архитектура почти догнала монолитный подход, с 23% и 25% соответственно. А что неожиданно, так это появление в списке serverless-архитектуры, пусть и с минимальной популярностью в 1%.

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

Oracle DB лидирует в гонке баз данных, и почти каждый третий заявляет, что использует её. MySQL и Postgres делят пьедестал с 24% и 22%. MongoDB — самое популярное NoSQL-решение с 6%. Наш любимый вариант здесь — Neo4J (1%), самая заметная графовая база данных. Даже учитывая, что графовые БД являются довольно нишевым способом моделирования данных, на это все равно стоит обратить внимание.

В прошлом году Oracle DB также был лидером, но в гораздо более жёсткой конкуренции: MySQL отставал от всего лишь на 1%. Однако тогда это был вопрос с множественным выбором, где респонденты сами указывали все используемые базы данных. Поэтому разница между результатами прошлого года и нынешнего может быть артефактом выборки или просто показывать то, что когда дело доходит до больших и наиболее важных проектов, выбор остается всё-таки за Oracle.

Вам нравятся инструменты, которые вы выбрали?

Хорошо, с популярностью инструментов разобрались. Теперь давайте посмотрим, любят разработчики свои инструменты или ненавидят. В опросе мы попросили оценить, насколько удовлетворены респонденты инструментами, которые они выбрали, по шкале от 1 до 10. Разберём их в том же порядке, в котором смотрели на популярность.

Неудивительно, что все IDE любимы. Средние оценки для IDE колеблются около 8 (из 10). В конце концов, IDE очень часто является личным выбором. Если вы не удовлетворены своим текущим IDE, скажем, NetBeans, вы всегда можете посмотреть на другие: Eclipse IDE или IntelliJ IDEA.

С данными не поспоришь, поэтому приходится признать: NetBeans имеет самый высокий рейтинг удовлетворенности из трех основных Java IDE, с оценкой 8.8. IntelliJ IDEA, доминирующая на рынке, в этом опросе очень близка с 8,7. Eclipse отстаёт с 7,5.

Тут сложно сравнивать на основании одного числа, поэтому для большего понимания, приведем стандартные отклонения для всех трех вариантов ответа: NetBeans — 1.27, IntelliJ IDEA — 1.1, Eclipse — 1.42. Это говорит нам о том, что в случае с Eclipse больше всего непостоянства.

Когда мы переходим к языкам программирования, видим очень похожую картину. В нижней части находится «зомби» Java 7 и старше, хоть и с неплохой оценкой 7.3 (из 10). Удивительнее, что у JavaScript оценка выше — 7.5. Это позволяет ему избежать последнего места — поразительно, учитывая, как часто люди возмущаются его кошмарностью. Возможно, люди, которые постоянно используют этот язык, оценивают его иначе, чем те, кто его попробовал его только один раз.

Поздравляем Kotlin, ведь он занял первое место с наивысшим показателем удовлетворенности 9,1 (самый высокий показатель по всему отчёту, а не только в вопросе о языках программирования)! Похоже, Kotlin — это то, чего вы хотели бы от Java, и похоже, использующие Kotlin разработчики действительно довольны решениями, принятыми командой Kotlin в дизайне языка. Молодцы, JetBrains!

Стек приложения — это нечто довольно личное для вашей системы. Он поддерживает ваш код и работает с ним, как системный администратор: когда всё замечательно, он невидим, но как только что-то идёт не так, вы в ярости. Но довольно сентиментальных отступлений. Spring имеет наивысшую оценку удовлетворённости 8,2 (из 10) и возглавляет рейтинг.

В реактивный стек мы собрали Play Framework, Lagom от Lightbend и Vert.x, поскольку принцип работы более важен, чем реализация. И все они оказались на втором месте со средней оценкой удовлетворённости 8.1. Удивительно (да, порой все мы оказываемся в «пузыре мнений» Твиттера), но результат Java EE очень близок к 8, да и в целом почти любой подход имеет достойный результат, за исключением внутренних разработок.

Честно говоря, у низкой оценки внутренних разработок причина может быть не только в том, что написать хороший фреймворк сложно, и опенсорсные обычно справляются лучше. Мы некорректно озаглавили вариант ответа «разработанное внутри компании чудовище», и с сожалением признаём, что такая формулировка могла сказаться на оценках.

В вопросе «насколько вы удовлетворены выбором архитектуры в своем главном проекте» получилась интересная картина: чем меньше вам нужно беспокоиться о своей архитектуре, тем больше вам это нравится.

Главное место занимают библиотеки и фреймворки с прочным 8.3. Действительно, при работе с JAR-файлом внутренняя архитектура намного проще, чем в полномасштабном приложении с аналитикой, мониторингом и т. д.

Затем идут serverless-архитектура и микросервисы с 8.1 и 7.9 соответственно. В нижней части таблицы удовлетворённости мы находим монолиты с 6.3. Всё ещё не «ужасно».

Быть недовольным своей базой данных — это, пожалуй, самая большая возможная неудача. Скорее всего, её дороже поменять, чем что-либо ещё, это зачастую нелёгкая задача, а выигрыш может быть сомнительным. Помните, как Uber переехал за несколько лет сначала в MySQL, а затем обратно? Если вы не удовлетворены своей базой данных — сочувствуем, скорее всего, она всё равно останется той же.

Postgres занимает первое место с оценкой удовлетворённости 8.4 (из 10). Redis дышит в спину с 8.3. Что удивительно: нишевые решения вроде Neo4J или Cassandra получили оценки ниже, чем более популярные. Можно было бы предположить, что если уж берёшься за нишевое, то потому что всё взвесил и будешь с ним счастлив. Но, по-видимому, каждая технология имеет свои оговорки.

Почему вы используете инструменты, которые используете?

Теперь мы разобрались и с популярностью, и со статистикой использования. Обратим внимание на второй большой вопрос отчёта: почему вы используете инструменты, которые используете?

Начнём с IDE. Причины, которые были предоставлены в качестве потенциальных ответов для IDE: функциональность, уже имеющийся опыт, бюджет и требования компании или проекта.

Один из очевидных результатов в том, что 91% людей, использующих IntelliJ IDEA, выбирают её, потому что считают функциональнее всего остального! С одной стороны, это, вероятно, справедливое заявление. В конце концов, прежде чем отдать деньги за программное обеспечение, хочется оценить альтернативы. С другой стороны, снимаем наши шляпы перед JetBrains, которые сделали отличный продукт и убедили свою пользовательскую базу в том, что он лучше, чем все остальные. Воспитание пользователей — это трудная задача, особенно в случае, когда альтернатива не требует кредитной карты!

Основная причина, по которой разработчики предпочитают Eclipse IDE (56%), — то, что с этим вариантом они уже знакомы. Действительно, лучше хорошо знать свои инструменты, чем иметь сложный инструмент, который вы не можете правильно применить. Но для Eclipse это незавидное положение, потому что люди пользуются продуктом по инерции, а не считают его действительно лучшим. Вероятно, это причина, по которой популярность со временем падает.

Примечательно, что 73% пользователей NetBeans также используют его из-за функционального превосходства. Это может сбивать с толку, так как обе IDE не могут быть функциональнее одновременно. Мы полагаем, что обе стороны сравнивают свою любимую IDE с Eclipse или просто работают над совсем разными задачами.

Разработчики любят ненавидеть языки программирования, которые они не используют. Иногда они даже ненавидят те, которые используют постоянно. Но ясно одно: большинство разработчиков предпочитают языки, которые они считают превосходящими по функциональности.

Когда мы говорим о подборе команды, которая сможет создать и поддерживать проект, Java является лучшим выбором: у 1 из 5 разработчиков, работающих на Java 7 и старше, был сделан такой выбор, потому что команда знает его. Политика компании и «застывшие» требования к проекту часто замедляют прогресс: 38% людей, использующих Java 7 (или старше), делают это, потому что таково требование к проекту или компании.

Альтернативные JVM-языки используются, потому что люди явно любят их. Те, кто выбрал Kotlin, Groovy или Scala в качестве основного языка программирования, аргументируют это тем, что они превосходят все остальные. С JavaScript картина другая: никто не называет его обходящим по функциональности, но всем нравится его сообщество и то, насколько обширна экосистема JavaScript.

Когда мы смотрим на причины, по которым разработчики решили использовать конкретный стек приложений, вырисовывается другая закономерность. По-видимому, во многих проектах есть очень конкретный набор требований. Это главная причина для выбора «лёгковесных» фреймворков (51%), главная причина не использовать какой-либо стек (64%), и при выборе реактивного стека это также важно (31%).

Да и при использовании внутренних решений, где есть всего две причины («требования проекта» и «политика компании»), это занимает 42%.

Самые популярные стеки — Spring и Java EE. Респонденты голосуют за них по разным причинам, но в обоих случаях экосистема превосходит всё остальное.

Говорить о выборе чего-то столь же важного, как архитектура ваших проектов, никогда не бывает легко. Похоже, что на вопрос «Почему вы это сделали?» правильный ответ — классическое «Это было разумно на тот момент». Если через какое-то время этот выбор всё ещё выглядит осмысленным, ответ превращается в «архитектура подходит для решения проблемы». А если не так, то это легаси.

Учитывая это, ответы о причинах выбора архитектуры не особенно революционны. Большинство решений было выбрано потому, что они хорошо решают проблему. Однако можно заметить кое-что интересное. 14% проектов, построенных на микросервисах, выбрали их из-за хайпа. Возможно, в каких-то случаях, это был эксперимент, чтобы понять, как оно пойдёт.

Тем не менее, шумиха — сомнительная причина для выбора архитектуры программного обеспечения. Другая интересная находка заключается в том, что десктопные приложения и монолиты оказываются в меньшей степени подходящими проекту. 29% и 41% голосов соответственно ушли за их выбор по легаси-соображениям. Сплит-архитектура (frontend / backend) также довольно часто выбирается по той же причине (20%).

Просто ли изменить сделанный выбор?

Мы собрали больше информации, чем можем представить в этом отчёте, поэтому публикуем только самые важные или показательные результаты.

При создании опроса мы подумали, что разумно спросить людей, которые не удовлетворены их инструментами (ставят им не больше 5 по шкале 1-10), почему они не переходят к чему-то другому. Но для некоторых инструментов это не имело большого смысла: например, для баз данных. Никто не меняет базу данных по прихоти. Либо это фиксированное требование, либо замена стоила бы целого состояния. Но мы хотели бы рассмотреть этот вопрос для выбора IDE и стека приложения. Они ближе к разработчикам, чем к организации в целом, и ресурсы на их смену могут быть разумными.

Почему бы вам не изменить IDE, когда вы недовольны? 19% разработчиков говорят, что в бюджете недостаточно денег. Это, скорее всего, означает желание перейти к IntelliJ IDEA Ultimate Edition: из «большой тройки» только она требует приобретения лицензии. 18% (почти 1 из пяти) предпочитают участвовать в гонках на квадратных колёсах. То есть, они знают, что выиграют от перехода, но не могут выделить на него время. Ну, для такого могут быть и веские причины — например, большая команда, требующая от всех координированных действий, или постоянная борьба с проблемами в продакшне, как в классическом devops-кошмаре.

Еще у 12% нет времени на обучение использования другой IDE. Вместе это составляет 30% разработчиков, которые недовольны текущим выбором, но не могут его изменить. Если вы узнаёте себя, возможно, вам стоит посмотреть в сторону JRebel (да, это наглая самореклама). Говорят, этот плагин помогает сэкономить время. Возможно, вы сможете реинвестировать это время в изучение лучшей IDE. Если у вас действительно получится так, напишите автору этого отчёта, он будет крайне рад услышать вашу историю. Что же до остальных 51% разработчиков, недовольных своими IDE, они застряли с ней из-за требований своей компании.

Диаграмма со стеком приложений очень похожа. Почти половина (45%) несчастных пользователей говорят, что это требование, и они не могут изменить его по своему усмотрению. 29% признают, что идут на компромисс, заявляя, что у них нет времени или денег на миграцию проекта. Хорошо, что только 5% респондентов говорят, что им некогда научиться новому стеку.

Являются ли DevOps и производительность просто словами?

Помимо вопросов об инструментах и причинах их использования, мы включили пару вопросов о важных, но сбивающих с толку областях разработки программного обеспечения: о производительности и DevOps.

Важная вещь, которую можно заметить — это то, что у 14% опрошенных в команде есть «DevOps-инженер». Это весьма запутывает, поскольку DevOps — это культурная среда, где команда Dev и команда Ops разделяют обязанности и помогают друг другу. Остаётся неясным, как за это отвечает один человек. Четверть респондентов говорят, что у них dev-и ops-команды работают вместе, а 17% с гордостью говорят, что они и есть DevOps.

Затем мы спросили, в чем была основная причина внедрения DevOps (или почему его хотели бы внедрить). Главными тремя причинами оказались: быстрее выкатывать пользователям новые фичи (27%), получить стабильную операционную среду (21%) и быстрее разрешать производственные проблемы (18%).

Кто-то может сказать, что, по крайней мере, некоторые из этих целей могут быть достигнуты за счёт правильной настройки протоколов мониторинга, CD и CI для поставки, в том числе, на производственные среды. И тогда командам не нужно бросаться в DevOps с головой. Но, возможно, переход к DevOps — это способ согласовать, как реализовать процессы, связывающие среды разработки и продакшна.

Следующим мистическим элементом разработки программного обеспечения, который, как нам известно, вызывает много споров, является забота о производительности вашего кода. Это настолько интересный вопрос, что мы выделили для него весь отчёт о производительности разработчиков 2015-го. Тогда мы хотели выяснить, как команды работают над производительностью своих продуктов, какие инструменты используются для контроля производительности, какие профилировщики они предпочитают и т. д. Теперь, два года спустя, мы спросили, каково ваше отношение к работе по производительности в целом. Мы попросили выбрать наиболее подходящий ответ из списка.

К сожалению, 36% респондентов заявили, что они реагируют только тогда, когда пользователи жалуются. 21% используют какие-то средства мониторинга, чтобы узнать, когда приложение становится медленнее в продакшне. И только 22% используют какие-то нагрузочные тесты для проверки изменений до того, как они перетекут на продакшн-площадки. Картина получается довольно грустная.

При ответе на вопрос о своём подходе к производительности почти половина респондентов (47%) говорит, что производительность напрямую влияет на успех их проекта или компании. Это те, кого она волнует. А 26% не заботятся о производительности, потому что в требованиях её никогда нет. Возможно, если всё страшно затормозит, придет время отреагировать, но до тех пор — зачем беспокоиться?

Удивило то, что при вопросе «почему вы выбрали такой подход» 12% сказали, что инструменты и эксперты слишком дороги, чтобы правильно заботиться о производительности. А 15% говорят, что не знают, как подойти к проблеме.

Если вы разделяете это мнение, возможно, вам стоит взглянуть на XRebel Hub от ZeroTurnaround — APM для разработки и тестирования. С этого можно начать.

Мир в огне, или у нас есть шанс?

В целом можно увидеть, что разработчики довольны (около 7 баллов из 10) их инструментами. А если спросить их напрямую?

Считают ли они, что они продуктивны, выбранная технология хорошо их поддерживает, и дальнейший путь ясен?

Большинство наших респондентов сказали, что они довольны (63%). Некоторые (12%) видят корень своих проблем в возрасте проекта, с которым они работают. Только 1 из 10 признают, что им нужно изменить инструменты, с которыми они работают. Примерно такое же количество людей (8%) сознательно остаётся с менее продуктивными инструментами, чтобы упростить поддержку.

Когда мы смотрим на факторы, которые сильнее всего тормозят команды, на «бутылочные горлышки», картина немного отличается. Мы знаем, разработчики любят говорить, что их IDE делает их суперпродуктивными. Таким образом, каждый, кто использует другие IDE, должен быть менее продуктивным, не так ли? Мы спросили, что является самым больным узким местом, препятствующим улучшению, которое привело бы к максимальному повышению производительности.

Неудивительно, что в первую очередь упоминают масштабные вещи, которые сложнее всего изменить. 28% считают, что архитектура их проекта требует реконструкции. Интереснее, что многие разработчики считают, что им мешает недостаток DevOps. 14% заявили, что именно DevOps мог бы дать им самый большой импульс. Если вы помните причины для внедрения DevOps, мы можем предположить, что они хотят, чтобы полностью функционирующий непрерывный конвейер поставки позволял быстрее выкатывать фичи и исправлять баги.

9% довольны уже сделанным выбором инструментов, но хотели бы добавить к ним новые. Только 3% респондентов считают, что изменение их IDE даст им значительное повышение производительности. Их меньше, чем тех, кто думает, что проблема в базе данных.

Увлекательные мелочи

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

Мы знаем, что никто не меняет архитектуру, потому что это дорого и требует обновления проекта. То же самое касается баз данных. Если вас интересуют более конкретные вопросы, например «какие ещё инструменты используют те люди, которые используют NetBeans», посмотрите данные. А мы предлагаем вашему вниманию ещё пару интересных наблюдений.

В каких странах разработчики наиболее счастливы в выборе инструментов? Чтобы ответить на этот вопрос, мы усреднили средние значения для IDE, языка программирования, стека приложений, архитектуры проекта и баз данных по странам, указанным респондентами.

Наибольшее из средних значений, в 8,8 из 10, принадлежало Южной Корее! Самое низкое — Бельгии. Нет никакой информации, которая бы объясняла, почему это так. Но строить теории весело, так что попробуем! Бельгия — дом Devoxx, одной из самых известных и крупнейших Java-конференций. С качеством докладов на Devoxx может конкурировать только посредственность сэндвичей на их обедах. Возможно, воздействие людей, демонстрирующих свои удивительные инструменты и объясняющих, как правильно ими пользоваться, сделало респондентов из Бельгии менее удовлетворёнными их текущим выбором.

Еще кое-что, что мы нашли интересным — пусть и немного предсказуемым — то, насколько счастливы разработчики в командах разного размера. Итак, аналогично приведённому выше примеру, мы усреднили значения удовлетворённости разными инструментами по размеру команды. Оказывается, всё не так уж плохо, когда размер команды увеличивается.

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

И теперь, чтобы подвести итог, давайте рассмотрим, какие технологии разработчики считают восхитительными. Мы спросили:

Какой инструмент, технология или библиотека вас очень впечатлила или заставила гордиться тем, что использовали её (или планируете использовать) в 2017 году?

Это был открытый вопрос, в котором каждый мог писать о самой большой, самой увлекательной технологии, с которой он работает. Мы обрабатывали эти данные, заменив все синонимы на самый общий термин, например «Java EE 8» — на «Java EE», а разные версии Spring Boot были объединены в просто «Spring Boot».

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

Поздравляем команды JetBrains и Kotlin! Вы отлично поработали! В настоящее время Kotlin является одной из самых захватывающих технологий как на JVM, так и на Android. Будем надеяться, что это путь в светлое будущее для многих, многих пользователей!

TL;DR и ключевые выводы

Да, вы это сделали! Или, может быть, просто прокрутили вниз, чтобы увидеть, есть ли тут резюме, которое занимает меньше 30 страниц текста. В любом случае, поздравляю, что добрались. В этом кратком разделе мы обобщили наиболее важные результаты отчёта.

• IntelliJ IDEA — самая популярная Java IDE, ей пользуются 54% опрошенных.
   

• Пользователи NetBeans наиболее удовлетворены своей IDE, давая ей рейтинг 8,8 (по шкале от 1 до 10).
   

• Переход на Java 8 продолжается, почти 72% разработчиков заявили, что их основным языком программирования является Java 8.
   

• 47% используют Spring как основной стек приложения.
   

• 33% используют Java EE.
   

• Сплит-архитектура с раздельными фронтендом и бэкендом является самой популярной (34%).
   

• Микросервисная архитектура почти догнала монолиты — 23% и 25% соответственно.
   

• Самые популярные базы данных: OracleDB с 33%, MySQL с 24% и Postgres с 22%.
   

• Наиболее популярным хранилищем данных noSQL является MongoDB (6%).
   

• Kotlin — самый любимый язык программирования с удовлетворенностью в среднем 9.1 (из 10).
   

• Spring — хороший стек приложений со средним рейтингом удовлетворённости 8.2.
   

• Удовлетворённость внутренними разработками не слишком высока (5,2 из 10).
   

• Респонденты, использующие Postgres, более прочих довольны выбором своей базы данных: 8.4 (из 10).
   

• Основная причина использования IntelliJ IDEA и IDE NetBeans — «функциональность». Это утверждают 91% пользователей IntelliJ IDEA и 73% пользователей IDE NetBeans.
   

• 56% разработчиков, использующих Eclipse IDE, называют причиной то, что уже знакомы с этим инструментом.
   

• Только 19% несчастных разработчиков не меняют свою IDE из-за финансовых затрат. 18% хотят мигрировать и знают, что будет лучше, но у них нет времени.
   

• Самый популярный подход к DevOps — «команда Dev и команда Ops работают вместе» (25%). 17% заявили, что являются DevOps, а 14% говорят, что у них есть DevOps-инженер.
   

• Основной причиной внедрения DevOps является доставка функций заказчику быстрее (27%).
   

• 36% разработчиков реагируют только на жалобы пользователей о производительности, а не тестируют её сразу.
   

• 47% респондентов говорят, что производительность напрямую влияет на итоговый результат их проекта. 15% не знают, как правильно позаботиться о производительности приложения. 26% даже не имеют производительности в качестве требования.
   

• Архитектура проекта является наиболее распространённым узким местом для продуктивности разработчиков. 28% сказали, что именно это изменение даст наибольшее ускорение, большее, чем изменение чего-либо еще.
   

• Только 3% респондентов считают, что изменение IDE является ключом к проблемам с производительностью разработчиков.
   

• Kotlin — технология, который приносит больше всего радости своим пользователям.

Резюме и комикс напоследок

В этом отчёте мы попытались выяснить, какие инструменты используются Java-разработчиками и почему они их выбрали. Данные для этого анализа были собраны в публичном опросе RebelLabs. Мы получили около 2060 ответов. В отчёте основное внимание уделяется 5 категориям инструментов: IDE, языкам программирования, стекам приложений, базам данных и архитектурам проектов. Нам также было любопытно, почему люди хотят или не хотят внедрять культуру DevOps в своих командах и как они подходят к вопросам производительности приложений.

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

Напоследок: вот выпуск комикса xkcd, который заставит вас задуматься, следует ли вам менять некоторые из используемых инструментов на лучшие.