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

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


    У пользователей 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. Нужно разрабатывать подключаемые (из-за того, что окружения разнообразны) экспертные системы, которые помогут разработчику принимать решения в процессе работы.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 15

      +16
      вода
        –2
        Услышал, отредактирую, чтобы было яснее и четче.
        +1

        Какой iDE использует автор? :)

          0
          Отвечу цитатой aragaer: «весь мой линукс это моя IDE» )
          +2
          сразу закрывает проблему отладки принтами и неумение многих программеров пользоваться дебагером.

          Интересно, в чем проблема с отладкой принтами?
          Я практически всегда отлаживаюсь принтами и только очень редко лезу в дебаггер.
          ИМХО, принты примерно в 10^3 раз универсальнее и лучше, чем дебаггер.
            –1
            Самый раздражающий меня — необходимость рестартить после изменения. Хоть и я чаще дебаггером пользуюсь, чем принтами, но с сессией дебаггера иногда этого ограничения нет (с кучей оговорок).
            А обычно проблема в том, что отладочные принты легко забыть удалить.
            Поэтому если и отлаживать таким образом, то рекомендуют использовать логгер вместо принта, т.к., как минимум, можно извне регулировать уровни.
              +2
              Забыть, это не проблема, это мелочь. Достоинства перевешивают. Главное достоинство это то, что в многопоточном или многопроцессорном режиме принты печатаются в момент выполнения.
              Что касается логгера, то я использую и принты и логгер. Логгер для того, что должно остаться в программе после отладки. Принты, для того, что дожно быть после отладки удалено.
              И гораздо быстрее вставить принт в нужные места, чем шагать в дебаггере. ИМХО.
                –1
                Если в дебаггере надо шагать, то вы делаете что-то неправильно.
                По остальному — +- да.
                  +2
                  А если не шагать, то чем дебаггер отличается от принта?
                  Конечно в нужном месте ставим точку останова и потом шагаем и смотрим что к чему. Возможно я что-то и делаю не так, редко использую.
                  0
                  принты (ок, логи) лучше дебагера
                  1) при отладке многопоточного\процессорного кода еще иногда с дебагером нет тех ошибок, которые есть без дебагера (это иногда решается запуском дебагера над релизной версией, но иногда — и это не помогает).
                  2) Не на всех платформах вообще есть этот самый дебагер (впрочем сейчас это реже, на самых массовых платформах он все-таки есть).
                  3) не всегда есть доступ к клиентскому оборудованию для запуска дебагера. Зато «создайте пустой файл print_debug.log, повторите свой сценарий, закройте приложение и пришлите нам этот файл» — это по силам сделать даже австралийскому аборигену (да, был и такой случай в практике).
                  0
                  хмм… а на чем вы код пишете, и где его запускаете, если не нужно рестартить после изменения?
                    0
                    Часто операций «отредактировал\запустил\посмотрел» несколько и они идут подряд. По сути, первые N перезапусков — это проверка гипотез. Часто можно проверять гипотезы непосредственно в дебаггере, подменяя результаты промежуточных вычислений.
                    Тогда можно их проверять не перезапуская сессию дебаггера через джампы с брейками в точках конца инициализации основного массива используемых данных и точке проверки.

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

                    К слову: статью отредактировал, чтобы убрать намеки на антагонизм дебаггер-журналирование. Потому что, это, во-первых, не то, что я хочу донести, а во-вторых, подобные противопоставления некорректны, потому что подходов к отладки больше, чем 2.
                0

                Очень странное заключение.
                Современные IDE, безусловно, не идеальны. Идеальными они вряд ли станут раньше, чем остановится прогресс (да и тогда не станут) — так как всегда есть к чему стремиться, и всегда есть вещи, которые были бы приятны и полезны, но реализация которых экономически не оправдана — дешевле и/или проще сделать ручками.


                Например, рабочее окружение (E) в моей практике — результат штучной работы. Ну не стоит оно автоматизации, реально — не стоит. А где стоит, там Докеры и иже с ним IAAC, которые вполне интегрированы в среду разработки.


                Я впервые учился на третьем ещё (если не ошибаюсь) Турбо Паскале. Его среда разработки, интегрированная (таки I!) с компилятором и отладчиком весьма далека от того, что я использую сейчас или о чём мечтаю. Является ли заявленная интегрированность данной среды "спекуляцией"? Безусловно, нет!


                Спекуляция — это, всё-таки разговор на пустом месте, без реальных обоснований. Несоответствие пусть даже на 100% обоснованному желанию — нормальное состояние для вещей, существующих в объективной реальности.

                  0
                  Вот как раз я и говорю, что рабочее окружение на совести пользователя, и ни о какой «изкоробочности» речи быть не может. А требования — следствие из этого.
                  О TP — это причина, почему я сделал акцент на современных. Я учился на нем же, там интеграция 100%, простота окружения позволяет.
                  Про обоснованное желание: описанные (пусть и шапочно) мной потенциальные системы рефакторинга, в общем-то, реализуемы без особого геморроя для отдельно взятого языка.
                  Построение экспертных систем — это, на самом деле, еще более горячая задача.
                  Цель статьи не нажаловаться, что, де, ИДЕ плохие, а показать, где можно выкопать решения.
                    0
                    Вообще, вы правы. Отредактировал.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое