Сегодня с нами Антон Архипов aka antonarhipov — разработчик и менеджер продукта JRebel в компании ZeroTurnaround, — и говорим мы о правильных средствах разработки и их неправильном использовании. Антон профессионально занимается разработкой на Java более десяти лет. Основные интересы связаны с языками программирования и инструментарными средствами разработки ПО. Очень любит vim и IntelliJIDEA. Часто выступает на международных конференциях — за спиной выступления на таких конференциях как JAX, JavaOne, Joker, JPoint, GeeCON, Jfokus, JavaZone, EclipseCon.
— Антон, чем вы занимаетесь в области Java-разработки?
— Последние шесть лет я работаю в компании ZeroTurnaround, и по долгу службы занимаюсь любимым делом – разработкой инструментов для Java-разработчиков. Наш известный продукт – JRebel для Java-разработчиков, и наш второй крупный продукт – это XRebel, тоже для Java-разработчиков, но больше для тех, кто занимается веб-разработкой. Я занимался первые три года JRebel, и последние три года участвую в создании XRebel.
— С чем вы выступите на конференции Joker 2016?
— У меня два доклада на конференции – один про Java байт-код, и второй про эффективное использование IDEA.
О средах разработки
— Популярность IDEA растёт, и я с удивлением обнаружил, что по данным опроса, проводившегося на сайте вашей компании, она в этом году обогнала Eclipse.
Позиции различных IDE среди опрошенных на сайте zeroturnaround.com
— Стоит признать: любой опросник врет. Это статистика, а как известно, «есть ложь, есть большая ложь и есть статистика». Среди тех, кто отвечал на этот опросник, IDEA – самая популярная IDE, но это не значит, что она самая популярная среди всех Java-разработчиков. Если мы посмотрим статистику среди пользователей JRebel, то Eclipse все равно будет ведущим IDE, с вполне уверенным перевесом — доля Eclipse — более 60%.
На самом деле интересно не то, какая сейчас доля пользователей у 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 2016 будет про инструменты, то вот вам полезные ссылки на уже утверждённые доклады:
- Кирилл Толкачев «Релиз-менеджмент с помощью Gradle»
- Martin Toshev «Spring RabbitMQ»
- Владимир Цукур «Путь от CRUD к Hypermedia API с Spring»
- Алексей Зиновьев «Что Spark грядущий нам готовит?»
- Владимир Красильщик «Vert.x: Красавица и Чудовище»
Автор: JUG.ru Group
