достоинства и недостатки ide и редакторов кода примеры
Редактор или IDE? Очередная попытка анализа
Хотелось бы в очередной раз поднять эту довольно спорную тему.
С тех пор, как я начал заниматься программированием, этот вопрос не даёт мне покоя, а многочисленные темы на форумах и хабре ясности не внесли. Плюс к этому, мне кажется, некоторые аргументы как за одну, так и за другую сторону не были приведены. А у тех, что приведены, неверно расставлены приоритеты и упущен контекст.
В статье я постараюсь исправить это упущение и расставить ещё немного точек над «ё».
Приглашаю всех поучавствовать в поисках идеального инструмента.
О моём опыте
Программировать я начинал ещё в ДОС. на Turbo Pascal-е. Причём, почему-то, IDE мы тогда использовали только для отладки, и то достаточно редко. Для писания кода предпочитали использовать некий безымянный edit.exe без всякой подсветки синтаксиса в связке с Volkov Commander. И этого хватало. Этим же способом я позже занимался ассемблером и, частично, C++.
Продолжая изучать C++ я перешел на Windows и, соответственно, Visual Studio — куда же без него. Застал версии, если не ошибаюсь, с 5 до 7. После простенького редактора это было нечто — кодогенерация и автодополнение вызывали восторг. Правда, во всём этом сгенерированном добре разобраться было практически невозможно, но это казалось неважным.
Через некоторое время я пересел на Linux и занялся веб-разработкой на php. Здесь параллельно изучал vim и для разработки использовал ZendStudio. В какой-то момент начал использовать только Vim для всего — превратил его, в соответствии с многочисленными руководствами в маленькую ide. В нём же написал свою первую велосипедную CMS на php.
Замечу, что до этого программирование не было основным видом моей деятельности. Да, я и для работы писал различные мелкие утилитки, делал темы для для WordPress, но основным родом деятельности было администрирование.
Как только я занялся разработкой профессионально — возможностей vim мне перестало хватать. Был сначала eclipse, потом netbeans, сейчас — phpstorm.
Последние пол-года героически пытаюсь освоить emacs, в т.ч. в качестве основной рабочей среды.
Так что у меня есть с чем сравнивать и, надеюсь, моё мнение будет достаточно обоснованным и агрументированным.
IDE? IDE.
Я долго думал, в какой форме привести сравнение преимуществ и недостаков сторон. Список для этого не очень подходит, т.к. простое перечисление не вполне отражает суть вопроса. Редактор и IDE не противоположности, а инструменты, чья область применения перекрывается в некоторой области. Преимущества редактора далеко не всегда является недостатками среды и наоборот. По этой причине дальше идут более-менее структурированные рассуждения на тему.
Начну, пожалуй, с одного из бесспорных преимуществ редактора — его богатых возможностей по работе с текстом и возможности всё делать не отрывая рук от клавиатуры. Cреды в большинстве своём так не умеют. Только вот нужны ли такие возможности при написании кода? При написании статьи или письма, думаю, удобно одним нажатием клавиши поменять местами 2 слова или передвинуть абзац вверх страницы. Но в тексте программы это, в большинстве случаев бессмысленно и требует рефакторинга. А платить за это приходится либо пальцедробительными сочетаниями клавиш emacs, либо не менее мозгодробительными командами в vim. А ведь это всё нужно поминать! То, что просто решается одним движением мыши, вроде перемещения окна или изменения их размеров, превращается в целый квест. Да даже выделить текст проще мышкой — точнее, быстрее, и на надо считать сколько там слов до нужнго места в тексте. Нет, программисту тоже могут быть полезны эти функции, но дело в том, что его временные затраты на собственно редактирование кода ничтожны, так что выгоды во времени не будет практически никакой. А вот значительное усложнение инструмента — налицо.
Программист 80% своего времени тратит на понимание написанного кода и перемещению по нему. Причём перемещению именно по коду, а не по тексту! И здесь ему редактор не может помочь абсолютно ничем. Список параметров метода во всплывающей подсказке не покажет, перейти к определению метода не позволит, синтаксис не проконтролирует. А IDE, даже самые простые, с этим справляются просто и элегантно. Я недавно потратил минут 10 на поиск определения одного метода в проекте при помощи silversearcher из emacs. Оказалось, класс был определён в другом модуле и т.п. 10 минут, вместо одного клика мышкой! Я в emacs, конечно, недостаточно опытен, поэтому пусть будет 5 минут, даже минута. Но всё равно соотношение впечатляет.
И вот здесь IDE показывает свой, пожалуй, единственный, но очень жирный плюс — это наличие синтаксического анализатор языка программирования. Среда «понимает» что она редактирует код. Редактор — нет. А это и автодополнение, и навигация, и подсветка синтаксических, а, иногда, и семантических ошибок. Кажется, излишество, приятная мелочь, баловство. Но оно, превращается в необходимость после того, как размер проекта привысит некоторый предел. А с учётом объемных современных фреймворков — этот предел наступает практически сразу.
Да, на проекте из десятка файлов и пары тысяч строк, этот плюс не проявляет себя во всей красе. Редактор тоже может выполнять то же самое автодополнение, но он никогда не отсеет бессмысленные, варианты. И если размер проекта приближается к 100 тыс строк и состоит из тысяч файлов не считая библиотек, то становится проблемно выбирать нужное название из мешанины из названий переменных, методов других классов, да и просто слов из комментариев (было такое в vim-е у меня, не знаю, может, исправили). Интеллектуальные подсказки избавляют от необходимости помнить названия нужных функций и их параметры. Часто это просто физически невозможно.
Кстати о проектах. Во всех IDE есть такое понятие. К нему привязываются настройки, ресурсы, можно осуществлять поиск и т.п. В редакторах это в лучшем случае открытый каталог файловой системы. Иногда чуть больше.
Интеграция с отладчиком в редакторах тоже оставляет желать много лучшего. Юнит-тестирование, логирование в какой-то мере спасают ситуацию, но, иногда без отладчика никуда.
Кто-то может возразить, что в современных редакторах многие из этих функций уже реализованы и ничем не уступают самым навороченным IDE. Не соглашусь. Во-первых, полноценных реализаций нет. Не работают они, как должны. Во-вторых, установка всего этого уже достаточно сложная задача. Да даже конфигурация внутренних функций редактора уже нетривиальна. Попробуйте, скажем, включить нумерацию строк в том же emacs! Плюс ко всему, часто нужный функционал реализуется десятком плагинов непонятно как между собой взаимодействующих. А часто ещё и имеющих десяток версий и веток, не всегда совместимых, странно настраиваюхся и т.п. Можно, конечно, потратить месяц, всё настроить и установить (что тоже удел энтузиастов), но это всего лишь приблизит редактор к уровню IDE. К примеру, вернёмся к тем же проектам — я пробовал и Project под vim и projectile под emacs и ещё некоторые плагины. Если Project ещё более-менее отвечает моим требованиям (хотя в последней версии мне вообще не удалось создать проект из-за багов), то projectile оставил исключительно негативные впечатления.
И тем не менее, у редакторов есть несколько областей применения, где они, как минимум, составляют достойную конкуренцию средам разработки.
Во-первых, они себя лучше показывают на мелких проектах. Нет смысла загружать IDE-комбайн для работы с проектом в 10-20 файлов. Проще в редакторе подправить 3-4 строки.
Во-вторых, в некоторых специфических областях все преимущества IDE нивелируются. Например, низкоуровневая разработка для linux. Я этим не занимался, но, судя по структуре кода и предпочтениям разрабочиков (около 70% — emacs и клоны, 25% — vim, 5% — какая-то экзотика вроде jed), IDE там делать нечего. Весь нужный код, с которым происходит работа, собран, как правило в одном-двух файлах, и не нужно прыгать в пределах всего проекта. Да и не сильно поможет автодополнение при выборе из десятка-двух функций с почти одинаковыми названиями.
В-третьих, редакторы могут работать не только с кодом. Всю их мощь можно задействовать при работе с csv или xml файлами. Либо чего-то другого, в чём иногда возникает необходимость, вроде статьи или письма. И не нужно переучиваться, искать удобную программу или запоминать горячие клавиши — всё под рукой, всё одинаковое.
В-четвёртых, возможность работы с языками, для которых нет вменяемой IDE. Скажем, с тем же ruby мне среда не сильно помогла. SublimeText-а оказалось достаточно. Хотя с большим ruby проектом я не работал, возможно, там бы IDE себя показала.
И в-пятых, пресловутая возможность расширения. При наличии хороших плагинов редактор становится очень удобным! Плюс специфическое удовольствие непрерывного тюнига своего основного инструмента и ощущение полного контроля над ним — дорогого стоит.
Итого
Я не очень люблю IDE, хотя так могло показаться по предыдущему тексту. Считаю их довольно монструозными, с кучей ненужных функций, медленными и требовательными к ресурсам. Да и лучшие из них довольно дорогие. Кроме того, я считаю, использование IDE расслабляет, и привязывает к себе. У редакторов, соответственно, всё наоборот. Плюс доступность и возможности тонкой доводки под себя. По крайней мере vim и emacs. В конце концов, они мне просто нравятся. Эту статью, например, я пишу в Emacs.
Но индустрия (и начальство) диктует свои требования. Если не использовать IDE, производительность значительно упадёт. Но никто не даст вам пол-часа на поиск пропущенной запятой в 10 тыс строках кода. Это всё должно выполняться автоматически и автоматически же исправляться. Мне тоже иногда нравится покопаться в коде без всяких инструментов — но на работе это непозволительная трата времени.
После всех своих проб и ошибок я сделал такой вывод — редактор можно использовать для разработки, но с IDE, после определённого предела он не сравнится и использование редактора для чего-то, за что вам платят — непозволительная роскошь. Да, если использовать правильные практики разработки, правильно проектировать/документировать код, следовать стандартам — можно сгладить врождённые недостатки редакторов. Но мы живём далеко не в идеальном мире, поэтому использование IDE — необходимость, независимо от нашего желания.
Популярные среды разработки и их недостатки
Важнейшим элементом в процессе разработки приложения является выбор правильной IDE, зависящий не только от платформы, но и уровня собственной подготовки. Давайте познакомимся с наиболее популярными из них методом «от противного», представляя не столько их преимущества, сколько наиболее часто встречаемые укоры со стороны разработчиков.
Начнём с официальных представителей лидеров мобильного рынка: Windows, Google и Apple.
Visual Studio 2015
Описание: один из старейших программных продуктов для создания как консольных приложений, так и обладающие графическим интерфейсом. Добавление сторонних плагинов позволяет серьёзно расширить функциональность среды, в том числе до кроссплатформенного состояния.
Недостатки: новичку будет просто невозможно самостоятельно разобраться с Visual Studio без прохождения специальных курсов и чтения литературы. Это продукт скорее для опытных разработчиков, обращающих внимание на качество редактора и функции тестирования.
Android Studio
Описание: относительно молодая и стремительно развивающаяся IDE, ориентированная на разработчиков приложений для Android.
Недостатки: скупые возможности персонализации проявляются в редакторе кода и общих настройках. Мелочь, а неприятно.
XCode
Описание: IDE, ориентированная на создание приложений для OS X и iOS. Для использования языков Objective C и Swift на сегодня это лучшее, а для некоторых задач и вовсе единственное решение.
Недостатки: многие разработчики жалуются на стабильность среды, вынуждающую вносить дополнительные изменения в свои проекты после выхода очередной версии. Кроме того, XCode относительно сложная IDE для самопознания новичком. Именно поэтому рекомендуем вам пройти наш бесплатный интенсив по основам языка Swift. На нем мы рассмотрим тонкости работы с этой IDE.
От официальных представителей перейдём к универсальным кроссплатформенным средам разработки:
Xamarin Studio
Описание: популярный инструмент разработки приложений под Windows, Phone, Android и iOS, использующий по сути только один язык — C#. Помимо непосредственно Xamarin Studio вы также можете пользоваться плагином для Visual Studio.
Недостатки: незначительные, но тем не менее регулярные ошибки, как непосредственно в самой IDE, так и в выходном коде. Также, несмотря на репутацию кроссплатформенной среды, портировать уже готовые приложения на Xamarin достаточно затруднительно.
IntelliJ IDEA
Описание: IDE, разработанная компанией JetBrains, позволяющая создавать программы на множестве популярных языков, среди которых Java, JavaScript, Python, Ruby, Groovy, Scala, PHP, C, C++.
Недостатки: производительность. Томительное ожидание выполнения компиляции, перекомпиляции, тестирования порой действительно раздражает.
Appcelerator Titanium
Описание: платформа для быстрого создания консольных и графических приложений для всех подручных устройств.
Недостатки: возможности, предоставляемые Appcelerator Titanium имеют и обратную сторону: генерируемые ошибки в коде, искусственные ограничения, недостаточно качественная документация.
Eclipse
Описание: среда разработки, изначально ориентированная на работу с Java, прославилась большим количеством внешних модулей, существенно расширяющих её функциональность (в том числе, это касается количества поддерживаемых языков).
Недостатки: существенная нехватка документации, нет единого сообщества разработчиков.
Netbeans
Описание: мощная IDE для разработки приложений на Java, JavaScript, Python, PHP, C, C++ и даже Ада.
Недостатки: невысокое быстродействие из-за концепции «всё в одном». Некоторые плагины (в том числе для разработки приложений для Android) имеют существенные ограничения функциональности.
PhoneGap
Описание: необычная среда разработки кроссплатформенных приложений, не требующая знания «родных» языков. То есть для того, чтобы создать приложение для Android, знание Java вам не потребуется. Используются JavaScript в связке с HTML5 и CSS3.
Недостатки: ограниченная функциональность вызванная непосредственно основной идеей нецелевой среды разработки.
А какими IDE пользуетесь вы? И какие у них недостатки?
Важнейшим элементом в процессе разработки приложения является выбор правильной IDE, зависящий не только от платформы, но и уровня собственной подготовки. Давайте познакомимся с наиболее популярными из них методом «от противного», представляя не столько их преимущества, сколько наиболее часто встречаемые укоры со стороны разработчиков.
Начнём с официальных представителей лидеров мобильного рынка: Windows, Google и Apple.
Visual Studio 2015
Описание: один из старейших программных продуктов для создания как консольных приложений, так и обладающие графическим интерфейсом. Добавление сторонних плагинов позволяет серьёзно расширить функциональность среды, в том числе до кроссплатформенного состояния.
Недостатки: новичку будет просто невозможно самостоятельно разобраться с Visual Studio без прохождения специальных курсов и чтения литературы. Это продукт скорее для опытных разработчиков, обращающих внимание на качество редактора и функции тестирования.
Android Studio
Описание: относительно молодая и стремительно развивающаяся IDE, ориентированная на разработчиков приложений для Android.
Недостатки: скупые возможности персонализации проявляются в редакторе кода и общих настройках. Мелочь, а неприятно.
XCode
Описание: IDE, ориентированная на создание приложений для OS X и iOS. Для использования языков Objective C и Swift на сегодня это лучшее, а для некоторых задач и вовсе единственное решение.
Недостатки: многие разработчики жалуются на стабильность среды, вынуждающую вносить дополнительные изменения в свои проекты после выхода очередной версии. Кроме того, XCode относительно сложная IDE для самопознания новичком. Именно поэтому рекомендуем вам пройти наш бесплатный интенсив по основам языка Swift. На нем мы рассмотрим тонкости работы с этой IDE.
От официальных представителей перейдём к универсальным кроссплатформенным средам разработки:
Xamarin Studio
Описание: популярный инструмент разработки приложений под Windows, Phone, Android и iOS, использующий по сути только один язык — C#. Помимо непосредственно Xamarin Studio вы также можете пользоваться плагином для Visual Studio.
Недостатки: незначительные, но тем не менее регулярные ошибки, как непосредственно в самой IDE, так и в выходном коде. Также, несмотря на репутацию кроссплатформенной среды, портировать уже готовые приложения на Xamarin достаточно затруднительно.
IntelliJ IDEA
Описание: IDE, разработанная компанией JetBrains, позволяющая создавать программы на множестве популярных языков, среди которых Java, JavaScript, Python, Ruby, Groovy, Scala, PHP, C, C++.
Недостатки: производительность. Томительное ожидание выполнения компиляции, перекомпиляции, тестирования порой действительно раздражает.
Appcelerator Titanium
Описание: платформа для быстрого создания консольных и графических приложений для всех подручных устройств.
Недостатки: возможности, предоставляемые Appcelerator Titanium имеют и обратную сторону: генерируемые ошибки в коде, искусственные ограничения, недостаточно качественная документация.
Eclipse
Описание: среда разработки, изначально ориентированная на работу с Java, прославилась большим количеством внешних модулей, существенно расширяющих её функциональность (в том числе, это касается количества поддерживаемых языков).
Недостатки: существенная нехватка документации, нет единого сообщества разработчиков.
Netbeans
Описание: мощная IDE для разработки приложений на Java, JavaScript, Python, PHP, C, C++ и даже Ада.
Недостатки: невысокое быстродействие из-за концепции «всё в одном». Некоторые плагины (в том числе для разработки приложений для Android) имеют существенные ограничения функциональности.
PhoneGap
Описание: необычная среда разработки кроссплатформенных приложений, не требующая знания «родных» языков. То есть для того, чтобы создать приложение для Android, знание Java вам не потребуется. Используются JavaScript в связке с HTML5 и CSS3.
Недостатки: ограниченная функциональность вызванная непосредственно основной идеей нецелевой среды разработки.
А какими IDE пользуетесь вы? И какие у них недостатки?
Текстовые редакторы vs IDE
В последнее время наблюдается тенденция бессмысленных, с моей точки зрения, дискуссий относительно того, что лучше, — текстовый редактор или IDE. При этом, в темах, где обсуждается данный вопрос, зачастую 400 и более комментариев. Значит, людей этот вопрос интересует. Значит, надо писать статью.
Итак, какие цели статьи?
1. Что же лучше для программирования: текстовый редактор или IDE
2. Vim и Emacs — не текстовые редакторы
1. Что же лучше для программирования: текстовый редактор или IDE
Начнем с того, чем является программирование. Программирование — процесс написание лексических, синтаксических, семантических правил, оговоренных в спецификации языка программирования (далее ЯП) с последующим его тестированием и получением удовлетворительного конечного результата.
Итак, программирование — это:
1. Написание правил, оговоренных в спецификации ЯП
2. Тестирование написанных правил
Вся суть споров возникает, ввиду того, что для реализации каждого пункта нет четкого набора правил. И у каждого человека, исходя из его личных или командных потребностей применяется определенный инструментарий. Иными словами, выбор инструментария для реализации полного цикла программирования, носит субъективный характер. И если два и более человек, которые не понимают этого, начинается спор или дискуссия, которая не несет в себе никакого результата, кроме обоюдной неприязни. Предлагаю разобрать каждый пункт по отдельности, чтобы отделить мух от котлет, иначе смысловая составляющая будет стремиться или равна нулю.
1. Написание правил, оговоренных в спецификации ЯП
Говоря более простым языком, программирование — это написание текста. Которое подразумевает под собой ввод, редактирование и навигацию, а так же подсветка синтаксиса (последнее и отделяет простой набор и редактирование текста, от программирования). Есть еще один пункт, но он будет рассмотен ниже. Эти действия являются достаточными для того, чтобы реализовать этот пункт. Все эти простейшие действия есть в любом текстовом редакторе или IDE. Вопрос только в
том, какие методы применяются и сколь велика их эффективность. На текущий момент есть всего три основных варианта реализации:
а) классический универальный
б) модальный
в) классический усовершенствованный
Классический метод ввода применяется практически во всех IDE и некоторых редакторах базового уровня (ярким представителем которого можно назвать mcedit, nano), так и текстовых редакторах, которые являются IDE базового уровня (которые маскируются под определение текстовый редактор для программирования). Ярким представителем которого является kate, geany.
Модальный метод ввода подразумевает под собой изменение поведения редактора в зависимости от режимов. Одним из самых ярких представителей является Vim. И форки этого одноименного продукта.
Классический усовершенствованный метод ввода в той или иной степени представлены во всех IDE и текстовым редактором для программиста, коим является Emacs.
И тут сразу начинаются споры от том, какой метод ввода, редактирования и навигации лучше в контексте программирования. И споры обычно руководствуются всего двумя пунктами:
1. Метод ввода, редактирования и навигации не принципиален
2. Метод ввода, редактирования и навигации принципиален
Обычно, когда встречается два и более человека, которые имеют диаметрально противоположный взгляд на этот вопрос, спор или диспут превращается в хаотичный монолог с двух сторон. Результат которого стремится или равен нулю.
У каждого есть своя правда, а истина — одна. И истина в данном случае заключается в том, что второй тип людей правы на 99.9(9)%. Эффективность важна в любом ремесле или его составляющем. Будь то вязание веников или написание текста. Почему? Потому, что повышение эффективности любого составляющего, неизбежно приводит к увеличению эффективности всего процесса в целом. Кто этого не понимает — тот не понимает и объяснить почему вряд ли получится. К сожалению или к радости, зависит от целей и стремлений оппонента\ов.
Итак, существует 100% времени, из которых определенный процент времени тратится на ввод, редактирование и навигацию по написанному коду. Увеличение эффективности составляющих приводят к увеличению продуктивности всего процесса программирования.
а) классический универальный
Особо сказать нечего. Этот способ является достаточным для «Написание правил оговоренных в спецификации ЯП». Больше сказать об этом методе управления текстом нечего. Все его преимущества и недостатки объяснять смысла нет т.к если бы недостатков было меньше, чем преимуществ, тогда бы не появились два альтернативных варианта управления текстом.
б) модальный
Ввод текста осуществляется в одном из режимов. Редактирование же и навигация — в другом\их режимах. Приемуществом этого способа является то, что при этих двух режимах не тратится время на перемещение рук программиста за пределы блока символов. Это означает то, что программисту не нужно перемещать руку на мышь или на стрелки влево\право\вверх\вниз и блок выше(insert\delete\home\end\page up\page down). С одной стороны — это увеличивает продуктивность, с другой, — избавляет от заболеваний суставов кистей.
в) классический усовершенствованный
Данный вид управления текстом появился ввиду недостака классического управления текстом. Далее излагаю свой, субъективный, взгляд на этот способ управления. Приемущества данного способа в том, что некоторые операции редактирования и навигации вынесены на определенные горячие клавиши. С одной стороны — это повышает продуктивность, с другой, при неудачном выборе горячих клавиш приводит к переутомлению мышц и\или к несвойственному положению рук или кистей и несвойственном движениям пальцев, что в свою очередь приводит к появлению такой болезни, как туннельный синдром.
Если сравнивать приемущество этого способа с модальным, а именно двумя яркими представителями двух способов управления — Vim и Emacs, то мало кто понимает то, что Emacs является тоже модальным, но у него модальность косвенная. И эта косвенная модальность — причина того, что многие выбирают Vim, нежели Emacs. Почему? Этот вопрос вы должны задать самому себе. Если не получится на него дать ответ, то скорей всего оно вам и не надо.
2. Тестирование написанных правил
Тестирование написанных правил осуществляется с помощью двух методов:
1. Встроенных в ЯП
2. Внешних инструментах (скрипты, cli инструменты)
И первый и второй пункт с реализуется как в текстовых редакторах, так и в IDE. Вопрос лишь в компетентности, трудоёмкости и целесообразности затраченных часов на их реализацию. При этом в продуктах Vim и Emacs, которые НЕ являются текстовыми редакторами, в базовой поставке реализованных методов или нет или они находятся в плачевном состоянии.
2. Vim и Emacs — не текстовые редакторы
Данные продукты не являются текстовыми редакторами. Это мощнейшие фреймворки, для построения высокоэффективных IDE. Т.к и один и второй — полностью программируемы. Начиная от изменения поведения, до интеграции инструментов обработки, с целью тестирования написанных правил.
Отсутствие функций, которые есть в классических IDE, говорит о том, что эти фреймворки используются людьми, которые применяют другие, отличные, методы для тестирования написанных правил, и этим людям\командам реализация оных не нужна. Единственным весомым аргументом из мира классических IDE является контекстное редактирование правил, которого нет в двух вышеуказанных фреймворках. И его нет по всё той же причине, которая была указана выше.
Вопрос: И всё же, что лучше, IDE или текстовые редакторы?
Ответ: Программируемые фрейморки, для построения высокоэффективных IDE! С одной оговоркой: если это необходимо.