Java DevTools: модно не значит хорошо
— Антон, чем вы занимаетесь в области Java-разработки?
— Последние шесть лет я работаю в компании «ZeroTurnaround», и по долгу службы занимаюсь любимым делом — разработкой инструментов для Java-разработчиков. Наш известный продукт — JRebel для Java-разработчиков, и наш второй крупный продукт — это XRebel, тоже для Java-разработчиков, но больше для тех, кто занимается веб-разработкой. Я занимался первые три года JRebel, и последние три года участвую в создании XRebel.
— С чем вы выступите на конференции Joker 2016?
— У меня два доклада на конференции — один про Java байт-код, и второй про эффективное использование IDEA.
О средах разработки
— Популярность IDEA растёт, и я с удивлением обнаружил, что по данным опроса, проводившегося на сайте вашей компании, она в этом году обогнала Eclipse.
Позиции различных IDE среди опрошенных на сайте zeroturnaround.com
— Стоит признать: любой опросник врет. Это статистика, а как известно, «есть ложь, есть большая ложь и есть статистика». Среди тех, кто отвечал на этот опросник, IDEA — самая популярная IDE, но это не значит, что она самая популярная среди всех Java-разработчиков. Если мы посмотрим статистику среди пользователей JRebel, то Eclipse все равно будет ведущим IDE, с вполне уверенным перевесом. 60–65% среди них занимает Eclipse.
На самом деле интересно не то, какая сейчас доля пользователей у IDEA, а то, как эта доля изменялась. Мы проводим эти опросники не первый раз, и все время показатели популярности растут для IDEA и падают для Eclipse. А для NetBeans они всегда очень маргинальны. Не то, чтобы 10% можно было считать маргинальным, но все-таки они достаточно низкие, с чем, конечно же, команда NetBeans очень не согласна. Они считают, что такие вещи вообще никак нельзя изучать через опросники. Но это всем интересно все равно, и все это всегда будут делать.
Мы видим тренд, что IDEA растет. И мне кажется, это связано с тем, что IntelliJ IDEA и компания JetBrains решили поменять стратегию выпуска новых версий. Чаще выходят апдейты, чаще выходят баг-фиксы, постоянно можно видеть «ранние релизы».
И когда какой-то продукт достаточно активно развивается, это привлекает разработчиков. Мы как дети, мы любим все новенькое. И чем мощнее инструмент, тем мы его больше хотим. Несмотря на то, что нам, например, 95% мощности этого инструмента, может быть, даже никогда не нужны будут.
Мне кажется, что один из больших плюсов IDEA в том, что её разрабатывает одна компания, с единым взглядом на то, как это должно выглядеть, как должен выглядеть продукт. У Eclipse я этого не наблюдаю. Там не наблюдается единой «линии партии», скажем так. И поэтому некоторые куски являются когерентными, а некоторые совершенно, как будто бы «ad hoc» в системе. Я не говорю, что в IDEA такого нет — в IDEA тоже местами есть беда, но она исправляется, когда сообщество начинает возмущаться: «Ребята, как же так, у вас коммерческое IDE». И там быстро-быстро стараются загладить эти шероховатости. В Eclipse, к сожалению, я этого не наблюдал.
Eclipse до сих пор — community-проект, даже несмотря на то, что за ним есть большие силы. Он следует своей довольно консервативной стратегии выпуска новых версий. К тому же, несколько лет назад были довольно большие проблемы с релизами, были, насколько я знаю, проблемы с производительностью и стабильностью. Но это случается у многих продуктов. И у IDEA был период, когда релизы были не очень хорошие, и у NetBeans тоже.
Единственный большой контрибьютор в Eclipse, который радеет за «единую линию» — это, мне кажется, Red Hat со своим дистрибутивом JBoss Developer Studio. Они стараются собрать такой дистрибутив, который ты поставил и который работает. И они являются таким «моторчиком» для Eclipse, чтобы улучшить его. Очень много последних улучшений в Eclipse связано именно с Red Hat.
— По существу, как вам кажется, программист на IDEA работает производительнее, чем в Eclipse? Вот вы будете по IDEA делать доклад. Наверняка вы в обеих IDE работали.
— Да, я работал последние двенадцать лет, с 2004 года, в IDEA. Eclipse я пользовался и контрибьютил в нее с 2006-го по 2008-й, и как-то еще немножко периодически использовал. Но по долгу службы мы делаем плагины для IDE. Наш продукт встраивается как плагин, и я как раз и занимался разработкой плагинов. Поэтому я все IDE последние несколько лет довольно активно использовал. Даже наблюдал, сколько у меня стояло разных версий Eclipse — порядка десяти штук.
— Но по большей части вы работали именно в IDEA? Тогда ясно, что для вас работа в ней производительнее, вы к ней привыкли.
— Да, во-первых, конечно, это дело привычки. Но помимо этого, я считаю, что для каждой задачи надо иметь свой инструмент, который вы хорошо знаете, и которым можно взять и сделать все, что угодно. Для каких-то вещей в разработке в Java мне было бы удобнее использовать NetBeans — я бы взял NetBeans для этой задачи. Для какой-то задачи мне было бы эффективнее использовать Eclipse — я бы взял Eclipse.
Для меня в IDE самая продуктивная часть — это навигация и система шорткатов. Очень часто люди ищут какую-то логику в системе шорткатов. Логики никакой нет, никогда. Мне, например, задавали вопрос: «Какая логика в таком-то шорткате в IDEA?» Неправильно так спрашивать, потому что, если смотреть, где какие шорткаты, везде можно увидеть какие-то странности. Почему Ctrl+H является поиском в Eclipse? Где здесь логика? Непонятно.
— Шорткаты, как аккорды — запоминаются мышечной памятью.
— Да, тут надо запоминать спинным мозгом, мышечной памятью и так далее. И тут главное, чтобы то, что ты хочешь сделать, ты мог бы сделать сейчас, и как можно больше out-of-the-box, не настраивая, не кастомизируя систему.
Тут как выбор между Mac или Gentoo Linux: или мы настраиваем всё под себя, или же мы берем и сразу едем, садимся в «Феррари» и шпарим сто километров в час.
Если человек может это с каким-то инструментом себе обеспечить, то он молодец. И тут уже не важно, IDEA или Eclipse. Я для себя это нашел в IDEA. Кто-то, может быть, найдет для себя это в Eclipse.
О системах контроля версий
— Вечный повод для «священных войн» программистов — это выбор системы контроля версий. Хочу поделиться своей историей. Когда-то давно наша компания сделала ставку на SVN, и теперь у нас много сотрудников (большинство из них — не Java-программисты или вовсе не программисты) обучены эффективной работе с SVN, многим трюкам и особенностям. А в последнее время мы видим, что Git всех разгромил по популярности. И часто возникают «продвинутые молодые специалисты», которые приходят и говорят: «Что же это вы до сих пор на Subversion? Вы устарели! Вы не в тренде! Как так?»
Популярность систем контроля версий
— В нашей компании по историческим причинам мы не используем Git во многих проектах. Есть команды, которые захотели перейти на Git — они перешли. Но у нас основное количество проектов и самые основные проекты содержатся в ещё менее популярной среде, чем SVN — это Mercurial.
Получили бы мы какие-то преимущества от перехода на Git или нет?
В своё время мы приглашали из GitHub тренеров, чтобы они провели нам тренинг по Git, для того чтобы мы решили, стоит нам переходить на Git или нет. И после этого дневного интенсива мы потом сели, подумали и поняли, что учитывая то, как мы работаем, от перехода на Git нам легче не стало бы. А для получения преимуществ от Git нам нужно было бы поменять свою работу.
Если ваш способ работы (делание бранчей, вот эти все вещи) подходит под вашу систему контроля версий и она это поддерживает, то это хорошо. Если мы берем инструмент, который позволяет кучу всяких классных вещей делать, а используем его все равно как SVN, то толку с этого мало.
Относительно популярности Git — тут работает вот какой момент, мне кажется: разработчики любят что-то очень мощное. Даже если эта мощность вся не нужна, мы хотим, чтобы оно было у нас под рукой — этот тесак. Даже пулемет, уже не тесак. SVN — это тесак, мы коммитили туда, и нас всё устраивало. Потом мы взяли Git-пулемёт и начали опять туда так же, как в SVN, коммитить. И тогда возникает вопрос:, а зачем все эти вещи?
— Да, если не умеешь хорошо играть, зачем тебе хороший музыкальный инструмент?
— Ну да. Я, честно говоря, не видел никогда для себя смысла очень сильно уделять время Git. Но сегодня, конечно, если меня кто-то спросит, какие инструменты разработчик должен знать, то в первую очередь я назову всё равно Git.
— Не обусловлен ли успех Git популярностью сервиса GitHub?
— Да, конечно, GitHub — он самый популярный, из-за него, мне кажется, популярен и Git. А во-вторых, тут работает зависть. «Я хочу тоже такое же, как у моего соседа, потому что у него мощно». И популярность Git тоже этим обусловлена.
— Многие апологеты Git напирают на децентрализацию. Я им отвечаю, что у нас SVN на три сервера реплицируется, у нас достаточно децентрализации.
— Ну, это разная децентрализация! Тут как раз, если у тебя децентрализованная команда, если у тебя все время разные проекты, разные прерывающиеся разработки и так далее, бранчи как раз являются силой Git. Если мы говорим о бранчах в SVN — это все-таки рудимент.
— Но это начинает работать, только когда очень большая команда и очень большой проект. А когда это в рамках небольшой компании, достаточно централизованной, то тут преимущества Git не дает?
— Тогда нет, конечно. Если маленькая команда, и если мы еще к тому же стараемся не делать много бранчей, или, например, всё разрабатываем только в одной основной ветке с так называемыми feature-флагами — тут преимущества Git теряются. Особенно, если маленькая команда.
О средствах автоматизации сборки
— Несколько угрожающе сейчас, если посмотреть на графики, для Maven выглядит рост популярности Gradle. Gradle, по-моему, повсюду, многие про него говорят. Стоит ли задуматься пользователю Maven о переходе на Gradle?
Популярность средств автоматизации сборки
— На эту тему мы делали замечательный доклад на прошлой конференции «JPoint» в этом году, с Барухом jbaruch Садогурским и Евгением Борисовым. Там у нас был эпический баттл — Maven, Gradle и SBT. Ну SBT там к слову, а в основном Maven и Gradle. И там в конце доклада Барух очень хорошо резюмировал, что для огромного количества проектов и сценариев Maven хватит за глаза. И Maven, благодаря своей «негибкости» так называемой — нельзя просто взять, всунуть руки и поправить логику билда — он как раз вот этим и берет. Он консервативный, стабильный, люди знают, как его «варить». Соответственно, он будет держаться на уровне 70%. И он держится, и мне кажется, что это не сильно изменяется. Это в том опроснике, может быть, как-то играют цифры.
— Gradle растет и отъедает у Maven его долю.
— Ну да. Но основные энтерпрайзные проекты все равно будут сидеть на Maven. В сторону Gradle будут смотреть, наверное, старые проекты, которые написаны еще на Ant, если их продолжат развивать в той логике.
— В логике императивного, а не декларативного подхода к сборке?
— Да-да. Для этого Gradle является вполне неплохим вариантом. Но у Gradle есть своя проблема: там очень легко написать «макароны». Многие эти «макароны» объясняют тем, что язык сборки, Groovy, не статический, типизированный.
Если в Gradle появится когда-нибудь ключик «Enterprise Mode, On!», который будет запрещать любые скрипты внутри build-файла, я думаю, это будет его первый шаг в enterprise-мир. В принципе, многие так считают. И Барух так считает, и я с ним согласен.
Мне кажется, что Maven — это все равно solid, это стандарт де-факто. Его должен знать каждый.
Gradle — это для тех, у кого действительно требования по сборке выходят за рамки. Gradle, мне кажется, не просто инструмент для сборки, он немножко более, он — инструмент для автоматизации, делать что-то большее, чем просто сборку. Он взял все хорошее из Maven, добавил Groovy, и мы теперь имеем такой мощный инструмент. Опять же, его популярность еще обусловлена тем, что он мощный. Мы опять возвращаемся к тому аргументу, что разработчики очень хотят мощность, даже не всегда, когда она нужна. И я уверен, что многие берут Gradle сейчас для каких-то новых проектов там, где он не дает никакого плюса по сравнению с Maven.
Я думаю, это какая-то инерция, к которой мы привыкли. Мы привыкли, что нам надо все время улучшаться.
— Но нам, разработчикам, все равно всегда надо улучшаться, у нас профессия такая.
— Может быть, нам надо просто остановиться и улучшаться в том, что мы уже имеем и что мы уже умеем, а не хватать новые фреймворки, инструменты и так далее. У нас есть хорошие инструменты, которые мы могли бы максимально освоить, и вышибать из них максимальную эффективность, из того, что у нас есть. А мы, не дойдя, не выжав хотя бы 90% и этих инструментов, уже кидаемся на новый инструмент, только потому, что кто-то сказал, что это более в тренде, более блестящее и более интересное.
— Понятно, спасибо за интервью! Надеюсь, мы с вами увидимся в октябре в Питере на Joker. Купил билет, жду — не дождусь.
Октябрьский Питер, конечно, не июньский, но тем приятнее будет участвовать в горячих спорах на Joker. И да, традиционно билеты будут только дорожать. Не говорите, что мы вас не предупреждали.
Если вам интересно, что на Joker 2016 будет про инструменты, то вот вам полезные ссылки на уже утверждённые доклады:
- Кирилл Толкачев «Релиз-менеджмент с помощью Gradle»
- Martin Toshev «Spring RabbitMQ»
- Владимир Цукур «Путь от CRUD к Hypermedia API с Spring»
- Алексей Зиновьев «Что Spark грядущий нам готовит?»
- Владимир Красильщик «Vert.x: Красавица и Чудовище»
