Современные IDE. Однозначно D, в какой-то степени E и уж точно не I

EclipseVIMEmacsСофт

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


У пользователей IDE, и разработчиков IDE есть проблемы с осознанным пониманием своих инструментов. Используются интуитивно и как попало. На удивление (приятное), такое использование почти не вступает в конфликт с незнанием, хоть и порождает соответствующие холивары на форумах.


Сейчас разберем, как обстоят дела в разработке с инструментами, что не так с понятием "IDE", и какие инструменты уже должны были появиться, но пока не были разработаны.


image


Е


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


  • Разные способы взаимодействия с пользователем, что дает большие расхождения на то, как проект запускается, и как тестируется. (CLI, TUI, веб-морды, GUI в смысле Qt, GTK, etc.)
  • Разные тестовые фреймворки (unittest в одном проекте, pytest в соседнем, если говорить в контексте Python). Сюда же попадают и обвязки разноуровневых тестов (например, объединение выводов автономных тестов и интеграционных через TAP)
  • Разные VCS, а где-то могут быть гибриды (Git, как клиент для Subversion в частном случае).
  • В пределах одного проекта могут использоваться, в том числе, и разные редакторы. Например, Vim или nano для правки сценария интерактивного ребейза в Git, для редактирования чанков при частичной регистрации изменений. Или для правки конфигов из-под рута.

И это далеко не все варианты, думаю, любой разработчик с опытом от 2‑х и более проектов может подбросить еще подобных примеров. Частенько их слышу в виде истории "Как я потратил двое суток, чтобы настроить проект на новой работе".
Отсюда можно заключить, что компоновка и настройка среды для разработки в любом случае лежит на пользователе.


Integrated?


Учитывая вышесказанное, имеет смысл рассматривать не "интегрированные", а "интегрируемые" среды.
Тогда, с точки зрения пользователя, хороший инструмент интеграции — это когда:


  • Окружение настраивается быстро.
  • Его конфигурацию можно хранить и переносить.
  • Возможность повторно поднимать рабочее окружение "одной кнопкой".
    Например, опытные юниксоиды частенько сводят "переход в рабочий режим" к одной команде.

"Быстро" здесь не значит "легко для новичка". Лично моя позиция в этом вопросе: зависимость сложности реализации решения задачи от сложности самой задачи должна быть, как минимум, линейной.


Другой неочевидный момент: интерфейс может быть не единым.
Самый частый пример — это использование в работе над проектом как с GUI, так и CLI.
Об использовании нескольких редакторов при работе в одной среде над одним проектом я говорил выше.


Development


Теперь мы можем приступить непосредственно к самим инструментам.


Рефактор-браузеры


Создать мощный и универсальный рефактор браузер нельзя просто потому, что рефакторинг сейчас не существует, как, условно, академическая дисциплина.
Книга Фаулера, все-таки, построена вокруг Java с минимальными шагами в сторону. Плюс приемы рефакторинга настолько привязаны к контексту "стиль-язык-библиотеки", что порождаются прямо на месте каждым отдельно взятым программистом.
Я считаю, что базовые принципы рефакторинга можно описать с точки зрения обхода дерева данных на участках кода, и уже из них выводить конкретные приемы. Для этого в реализации рефактор-браузера должен быть:


  • Легко расширяемый интерфейс (для отображения приемов, созданных разработчиком под его конкретные нужды)
  • Анализаторы, база (вышеупомянутые принципы) и схема редактирования должны быть сокрыты, чтобы оставить разработчику возможность расширять набор приемов без необходимости лезть в кишки его редактора. То есть, DSL для описания приемов рефакторинга.
  • Так как за расширяемостью последует резкий рост числа приемов, для отображения необходимо учитывать context scope, чтобы отображать в меню выбора операций лишь применимые в конкретной ситуации.

Runtime анализ дерева данных.


Этот аспект касается совмещения отладки и редактирования текста. Фактически, для подавляющего большинства языков, чтобы проверить, как влияют правки на работу программы, необходим явный перезапуск программы. Куда проще и наглядней (и, как следствие, с меньшим числом возможных ошибок), будет возможность увидеть в едином пространстве, как меняется весь массив данных в отлаживаемом участке кода прямо по мере редактирования кода.
Разработка подобного инструмента для разных языков сильно расходится по сложности, причем дело не только в синтаксисе, системе типов и особенностях исполнения, но в сути каждого отдельного языка. Для Data Driven языка такое построить намного легче. Пример: конструкторы регулярных выражений, где в процессе сразу видно, какие участки текста покрывает составляемая регулярка.


Информация и знания


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


  • Документация.
  • Приемы\эвристики разработки.

Во первых, для упрощения работы программиста, доступ до документации должен быть прямо из окна редактора.
Эту задачу неплохо решают разные IDE и редакторы: language specific IDE от Microsoft, Emacs с его Info-mode, Frescobaldi, Sunny Builder; причем как для интегрированной в исходники, так и для внешней. Однако, многие библиотеки и фреймворки сейчас выкладывают свою документацию только в сети и\или используют разные форматы для ее хранения, что усложняет возможную интеграцию в единый интерфейс.


Вторая же группа куда интересней.
Она охватывает знания, как программирование и разработку в целом, так и специфичные для конкретного языка\стека приемы. На данный момент, эту нишу практически целиком захватил Stack Overflow, и даже есть его интеграции в IDE, но качество экспертизы там, зачастую, низкое. По хорошему, куда более эффективно будет отобрать хорошие решения, ошибки, приемы и свести в некую базу, к которой пользователь может обращаться, когда ему необходимо решить какую-то свою проблему.
К тому же, современные анализаторы позволяют предупреждать о возможных, еще не соверешенных, ошибках. То есть, фактически, у нас есть, с технической точки зрения, все необходимое для создания экспертных систем для разработчиков, предлагающих решения по мере написания\редактирования кода. Не хватает только самих баз решений\приемов\ошибок.


Заключение


Итак, резюме:


  1. Развитие рефактор-браузеров должно отталкиваться от операций над деревом данных и сводиться к DSL-образному описанию сценариев автоматизированного редактирования кода.
  2. Runtime анализаторы должны придти к моментальному отображению изменений данных, в процессе редактирования и написания программы. То есть, подход JAI можно будет применять к другим языкам программирования.
  3. Из юзкейсов разработки убрать веб-браузер, как способ искать и читать документацию.
  4. Нужно разрабатывать подключаемые (из-за того, что окружения разнообразны) экспертные системы, которые помогут разработчику принимать решения в процессе работы.
Теги:emacsIDEAIDEVimSublimeинструменты разработчика
Хабы: Eclipse VIM Emacs Софт
-1
7,9k 18
Комментарии 15

Похожие публикации

Junior Clojure Developer
от 70 000 до 150 000 ₽Health SamuraiСанкт-ПетербургМожно удаленно
Middle IDE Developer (Java/Kotlin)
от 80 000 до 150 000 ₽HaulmontСамараМожно удаленно
Java Developer (GoLand)
от 200 000 ₽JetBrainsСанкт-Петербург
Middle/Senior Java Developer
от 150 000 ₽OptiSystemsКраснодар
Senior Software Developer (New IDE platform)
от 250 000 ₽JetBrainsМосква

Лучшие публикации за сутки