IntelliJ IDEA — IDE, которая понимает код

JetBrains

Игорь Савчук, dev.by

Продолжая традицию знакомства наших читателей с разработчиками известных программных продуктов (напомню про наши интервью о Delphi и ReSharper), мы решили познакомиться поближе с известной интеллектуальной средой разработки IntelliJ IDEA от компании JetBrains, которая применяется для разработки на многих языках программирования, но больше всего известна именно в мире Java. Собственно, именно благодаря этому популярному продукту на прошлогодней конференции JAX 2012 JetBrains стала обладателем громкого титула The most innovative Java company в рамках престижного JAX Innovation Awards с формулировкой “the most advanced IDEs for Java and many other languages and technologies”.

Сегодня в первой части интервью мы обсудим с разработчиком IntelliJ IDEA, кандидатом физико-математических наук Николаем Чашниковым сильные и слабые стороны этой IDE. Во второй части мы решили больше сосредоточиться на контексте — чем плохи Java, Groovy и Scala, и почему компания JetBrains решила создать свой собственный язык Kotlin.

Расскажите самое важное про IntelliJ IDEA для тех, кто вообще не знает, что это такое. С чем связана такая высокая популярность этой интегрированной среды разработки, в чём её особенности, уникальность?

IntelliJ IDEA — интеллектуальная среда разработки, которая понимает код. Когда программист пишет код, IntelliJ IDEA на лету строит синтаксическое дерево, определяет, куда ведут встречающиеся в коде ссылки, анализирует возможные пути исполнения операторов и передачи данных. Пользуясь этой информацией, она предлагает варианты автоматического дополнения кода, мгновенно показывает ошибки и даже потенциальные проблемы в написанном коде, умеет сама их исправлять. Наша IDE берёт на себя всю рутинную сторону программирования, позволяя пользователю сосредоточиться на существенной части работы. Разумеется, сама функциональность, предоставляемая в IntelliJ IDEA, есть и в других средах разработки. Но IntelliJ IDEA за счёт глубокого понимания кода делает использование этой функциональности более удобным и эффективным. Возьмём, к примеру, автодополнение кода. Там, где другая среда разработки предложит 10 возможных вариантов, наша IDE, проанализировав контекст, может отфильтровать варианты, не подходящие по типу возвращаемого объекта, и предложить только один вариант — именно тот, который и имел в виду пользователь. Это, конечно, мелочь, но, согласно собираемой в моей копии IntelliJ IDEA статистике, я использовал такой способ автодополнения более ста тысяч раз. Если каждый раз я экономил на выборе варианта хотя бы полсекунды, нетрудно посчитать, сколько времени мне сохранила одна только эта функциональность. А таких вещей в IDE множество. Вместе они не только повышают продуктивность программиста, но и увеличивают удовольствие, получаемое от работы. А это, согласитесь, не менее важно.

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

История IntelliJ IDEA начинается одновременно с историей компании JetBrains. Собственно, и сама компания первоначально называлась IntelliJ Software. Буква J в слове IntelliJ означала Java, поэтому, когда стали разрабатываться продукты, не связанные с Java, название поменяли. Компания была основана в феврале 2000 года, и в том же году были выпущены первые варианты продукта — IntelliJ Renamer и IntelliJ CodeSearch. Эти продукты ещё не были самодостаточными, их предполагалось использовать вместе с популярной тогда средой разработки для Java — JBuilder. В 2001 году уже в виде самостоятельной IDE вышла IntelliJ IDEA 1.0. С тех пор новые версии выходят ежегодно, и к концу 2013 года мы планируем выпустить 13-ю версию. Причина, по которой мы делаем собственные программные продукты, очень проста. Все свои продукты мы делаем, в первую очередь, для самих себя. Если в процессе работы мы видим, что существующие инструменты недостаточно хорошо выполняют свою задачу и нам приходится вручную делать то, что может быть автоматизировано — значит, нам надо создать свой собственный инструмент. IntelliJ IDEA появилась потому, что существующие на тот момент среды разработки для Java не имели средств автоматического анализа и рефакторинга кода. К примеру, чтобы переименовать метод в Java-классе, надо было запустить поиск и замену имени метода по всему проекту и вручную просмотреть все сделанные замены, чтобы убедиться, что не переименовывались вызовы методов с тем же именем из других классов. IntelliJ Renamer, первый вариант продукта, позволял выполнить переименование быстро и безопасно, автоматически определяя, какой именно метод вызывается в каждом случае.

Тот же мотив двигал нами и при создании других продуктов. Мы увидели, что существующие системы continuous integration и issue tracking нас не удовлетворяют, поняли, что в них можно улучшить, и создали свои системы TeamCity и YouTrack. Потом, когда недостатки самого языка Java стали ограничивать наши возможности, а имеющиеся альтернативы — Groovy и Scala — нам не подошли, мы начали разрабатывать свой собственный язык программирования Kotlin.

Расскажите, какие поддерживаемые вами языки пользуются самой большой популярностью? Есть ли уже стандартная для многих бесплатная редакция продукта?

Большая часть пользователей IntelliJ IDEA пишет, разумеется, на Java. Из других языков наиболее популярны Groovy и Scala. Чаще всего на IntelliJ IDEA разрабатывают Web-приложения, следующие по популярности — приложения для Android. Но IDEA уже давно поддерживает языки программирования и не из Java-мира. Для программистов на PHP, Ruby, Python и Objective-C мы даже создали отдельные продукты — PhpStorm, RubyMine, PyCharm и AppCode. Эти продукты строятся из того же исходного кода, что и IntelliJ IDEA, в них просто не включаются те части, которые не связаны с соответствующими языками.Хотя количество пользователей у последних производных продуктов существенно меньше, чем у центральной IntelliJ IDEA, но растут они гораздо быстрее. И, в целом, продажи продуктов нашей компании за последние годы демонстрируют уверенный рост. Выручка от продажи лицензий за 2012 год выросла на 45% по сравнению с 2011 годом. Вместе с нашими продуктами растёт и сама компания. За прошедший год мы наняли более 70 новых сотрудников, большую часть из них — в наш офис в Санкт-Петербурге. От этого в петербургском офисе стало, правда, тесновато, но в ближайшие месяцы мы переедем в отдельное новое здание на Васильевском острове. Кроме того, у нас есть офисы в Мюнхене, Праге, Москве и Бостоне.

Что касается лицензий — IntelliJ IDEA доступна в двух вариантах: Ultimate Edition и Community Edition. Ultimate Edition — полнофункциональная редакция, стоимость лицензии зависит от категории покупателя; для образовательных учреждений и разработчиков проектов с открытым исходным кодом мы предоставляем бесплатные лицензии. Community Edition — урезанный вариант, в котором нет поддержки для некоторых языков и интеграции с некоторыми инструментами, используемыми при написании Web-приложений. Community Edition распространяется бесплатно, более того, её исходный код открыт под лицензией Apache 2 и может быть свободно переиспользован в любых проектах.

Раз уж мы заговорили о статистике: я знаю, вы собрали очень интересные и отчасти неожиданные лично для меня данные по Flash/Flex-разработчикам, то есть про технологии, которые сегодня, согласно “народной молве”, медленно умирают. Согласно вашим внутренним данным, здесь не всё так просто… Так как обстоят дела у Flash на самом деле?

По нашим статистическим данным не всегда можно судить об общемировых тенденциях. В данном случае мы можем только уверенно утверждать, что растёт количество Flash-разработчиков, пользующихся именно IntelliJ IDEA. Мы предполагаем, что, скорее всего, это вызвано переходом с конкурирующих продуктов на наш, так как уровень поддержки этой технологии в IntelliJ IDEA находится на очень высоком уровне, и мы продолжаем инвестировать в эту область, тогда как не все конкуренты могут похвастаться тем же. Рынок Flash-разработки настолько велик, что даже в случае общего падения рынка мы ожидаем рост числа Flash-пользователей IntelliJ IDEA в ближайшие несколько лет и будем распределять наши приоритеты соответствующим образом.

Я знаю, что одной из главных фишек последней 12-версии стал ваш новый компилятор, который стал существенно лучше и быстрей. Можно более подробно рассказать про это новое “сердце” для вашей IDE?

В нескольких последних версиях мы целенаправленно занимаемся повышением производительности разных частей IDE. Нас к этому мотивируют, в том числе, и чисто эгоистические соображения: ведь количество файлов в исходном коде самой IntelliJ IDEA растёт с каждой версией. К 11-й версии количество Java-файлов достигло 50 тысяч, и полная компиляция стала занимать от 10 до 20 минут. Разумеется, полная компиляция требуется не так часто, IntelliJ IDEA умеет перекомпилировать только изменившиеся и зависящие от них файлы. Но когда над проектом работает большая команда, ежедневно меняется множество файлов, и компиляция начинает отнимать заметное время. Одной из причин, замедлявших компиляцию, было то, что код, управляющий компиляцией, работал в том же процессе, что и IDE. В 12-й версии мы переработали систему компиляции таким образом, чтобы вся работа происходила в отдельном процессе. У такого способа есть несколько преимуществ. Во-первых, стало возможным запускать javac в том же процессе, а не стартовать новый процесс для каждого модуля (а их в нашем проекте более четырёхсот). Во-вторых, мы теперь можем выделить больше памяти процессу компиляции, что позволяет хранить больше промежуточных данных в памяти, не сбрасывая их на диск. В-третьих, работая с javac в одном процессе можно теснее с ним интегрироваться, и, к примеру, инструментировать сгенерированные класс-файлы прямо в памяти. В-четвёртых, процесс компиляции перестал затормаживать работу самой IDE, так что появилась возможность запускать компиляцию автоматически.

Отдельной строкой хочу спросить о поддержке долгожданной Java 8. Что уже есть от спецификации Java 8, а что планируется сделать?

12-я версия IntelliJ IDEA уже поддерживает все новые конструкции языка, которые появятся в Java 8: лямбда-выражения, ссылки на методы, аннотации на типах. Дело, правда, осложняется тем, что работа над Java 8 ещё не завершена, и когда команда Oracle меняет какие-либо детали реализации новых конструкций, нам приходится вносить соответствующие изменения в свой код.

Также сейчас очень популярна мобильная ОС Android, в связи с этим думаю, многим интересен ваш продвинутый конструктор интерфейсов (Android UI Designer) для этой платформы. Я часто слышу от коллег, что ваш редактор интерфейса превзошел таковой в Eclipse (например, есть переходы по ссылкам в XML-ках и так далее). Можно ли рассказать подробней про него и его возможности?

Действительно, возможности редактирования интерфейса в XML файлах в Eclipse были сильно беднее. Впрочем, в последних версиях они повторили большую часть функциональности, предоставляемой в IntelliJ IDEA. В частности, навигация по ссылкам в XML теперь работает и у них.Но ради справедливости стоит сказать, что многие вещи в Eclipse менее удобны, например, подсветка ошибок работает не на лету, а только после сохранения файла. Визуальный редактор интерфейсов, который появился в IntelliJ IDEA 12, также в целом не уступает дизайнеру в Eclipse, а во многих мелочах превосходит его, к примеру, при использовании GridLayout.

Пока мы здесь — что насчет его долгожданных кастомных вьювов (custom Views in Android layout preview)?

В IntelliJ IDEA 12 есть поддержка для custom view. При условии, что нужные классы скомпилированы, custom view можно использовать в визуальном дизайнере наравне со стандартными компонентами.

Ну, раз уж мы заговорили про UI: некоторые представители ”старой школы” призывают молодежь “учиться рендерить xml в уме”, с другой стороны — подобные визуальные конструкторы хороши тем, что устраняют рутину и сильно снижают порог вхождения в программирование именно для новичков. В связи с этим у меня чисто субъективный вопрос: для кого вы сами позиционируете подобные визуальные редакторы, какие видите плюсы и минусы у подобного упрощающего подхода к программированию и проектированию?

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

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

Продолжение следует.

Впервые опубликовано на портале dev.by.