Вот некоторые принципы работы IDE (интегрированных сред разработки), которые, на мой взгляд, нужно зафиксировать:

Принцип минимальной навигации

Навигация в IDE раздражает. В тексте, конечно, можно выучить все причудливые навигационные сокращения типа C-a M-< M-f и так далее, но всё равно требуется немало набирать на клавиатуре. А если речь идет о навигации в файловой системе, то требуется еще больше ввода и поиска.

IDE должна минимизировать время, требуемое на навигацию. В частности, можно организовать автоматический импорт функции, когда пользователь набирает call-сайт, чтобы не переходить в верхнюю часть файла, чтобы добраться до импорта, или использование goto определения, чтобы не приходилось выяснять, в каком файле определен тот или иной класс.

Навигация также может быть связана с перемещением блоков кода, например, если вам нужно обратить оператор if, то это должно обеспечиваться на уровне кода, а не только при помощи манипуляций вручную.

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

Принцип использования для объявления

Мой пример с импортом функции во время набора также подчеркивает еще один принцип — IDE должна позволять пользователям создавать объявления. Если переменная не определена, IDE не должна просто выдавать сообщение об ошибке и отказываться работать. Пока пользователь не запутался, есть всего несколько вариантов: переменная определена неправильно; переменная еще не определена и необходимо добавить определение; переменная будет определена позже. Каждая из этих ситуаций может и должна быть решена средствами IDE. Имя может быть исправлено или определение сгенерировано автоматически.

В плагине для работы с Rust в IntelliJ недавно добавлена возможность указать новый вариант перечисления, если он не определен, но на самом деле так должно быть со всеми сущностями, которые могут быть объявлены. IDE должна позволять добавить параметр в случае неопределенной переменной. Она должна позволять добавить переменную типа, если таковая не находится в области видимости.

Этот принцип похож на семантику современных компиляторов, ориентированных на запросы, где компиляция определяется как запрос к фрагменту кода, а компилятор подтягивает дополнительные данные и определения, чтобы удовлетворить этот запрос. Пользователь должен иметь возможность определить, как будет использоваться символ, и затем объявить этот символ.

Принцип наименьшего запоминания

В описании программирования говорится, что оно требует одновременно держать в голове множество концепций. Это действительно так, но я считаю, что IDE должны способствовать тому, чтобы вам приходилось держать в памяти меньше понятий. В современных IDE очень распространена такая возможность как вывод параметров функции и их типов во всплывающей подсказке при указании вызова функции. Таким образом, можно проверить правильный порядок и типы параметров без необходимости запоминать их.

Самый старый прием, позволяющий запоминать меньше, — это использование окон. Открыв несколько окон, можно читать из одного окна, одновременно набирая текст в другом. Но работа с окнами — это очень грубое решение. Во-первых, оно громоздкое. Да, теоретически можно создать сетку окон 9x9, но это следующая проблема: каждое новое окно затрудняет чтение кода. Вы быстро забываете, где находится курсор, и область, в которой вы можете читать код, становится все меньше и меньше.

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

Принцип наименьшего чтения документации

Я был очень удивлен, узнав, что kdy1, создатель swc, не читает документацию. Как же он может использовать библиотеки без документации? Но, поразмыслив, я понял, что в наши дни это вполне осуществимо. Благодаря таким инструментам, как Copilot или TabNine, и эргономичному и строгому компилятору, такому как rustc, обычно удаётся разобраться в API без особых проблем. Я определенно отказался от чтения документации и использовал определение goto и некоторое автозаполнение, чтобы разобраться в библиотеках.

Это не значит, что я могу сравниться с kdy1. Я все еще очень часто полагаюсь на документацию. И хотя в документации становится все приятнее ориентироваться благодаря таким инструментам, как Docsearch, и таким соглашениям, как Command-K для поиска, это все равно не так эффективно, как использование IDE. Если IDE сможет сократить время, затрачиваемое на чтение документации, будь то интеграция документации в IDE или добавление дополнительных инструментов, таких как Copilot, то это, на мой взгляд, значительно ускорит процесс разработки.

Обратите внимание, что документация — это не только официальный текст на сайте библиотеки, но и выявленные проблемы на GitHub, запросы на исправление, вопросы на StackOverflow и даже сообщения в Twitter. Если бы я мог тратить меньше времени на поиск информации в различных источниках и больше времени на программирование, это было бы просто замечательно.

Принцип визуализации

Если и есть какая-то недооцененная особенность современных IDE, то это подсветка синтаксиса. Если вы когда-нибудь пытались реализовать подсветку синтаксиса, то, возможно, будете удивлены тем, как трудно в этом преуспеть. Долгое время подсветка синтаксиса основывалась на регулярных выражениях. Это означало, что можно было выделять цветом только широкие области: идентификаторы — зеленым, ключевые слова — желтым и так далее. Этого было недостаточно для того, чтобы пользователи могли отличить переменную от функции, выделить импортируемый метод от неимпортируемого или придать вызову метода определенный цвет. Подсветка синтаксиса внутри строк также весьма полезна, как для интерполяций, так и для самих выражений. Все это необходимые составляющие хорошей подсветки синтаксиса. Более того, можно утверждать, что подсветка синтаксиса способствует развитию некоторых возможностей языка. Без подсветки такие возможности, как регулярные выражения или форматирование строк, становится крайне сложно написать правильно.

Конечно, подсветка синтаксиса — это еще и то, что вы не выделяете. Большинство современных IDE стараются не перегружать пользователя пестрыми цветами, предпочитая выделять лишь несколько ключевых элементов.

Отсутствие подсветки также может очень красноречиво свидетельствовать о том, что код некорректен. Конечно, это может означать, что IDE еще обрабатывает код и пока не может его выделить.

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

Принцип обучения

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

Наряду с этим, я считаю, что существуют возможности для создания IDE, ориентированных исключительно на чтение кода, — интегрированной среды чтения, если хотите. IDE обычно работают на пределе производительности большинства компьютеров. Но если вы можете сделать кодовую базу неизменяемой, то IDE не придется тратить вычисления на обновление своей информации. Что же они могут делать вместо этого? Возможно, законы, подобные закону Линуса, т.е. «при достаточном количестве глаз все ошибки некритичны», можно развить еще дальше с помощью более совершенного инструментария. Если больше людей смогут читать кодовую базу, если мы сможем привлечь больше «глаз», то, возможно, удастся решить больше ошибок.

Принцип выявления особенностей

Возьмем, к примеру, структурный поиск и замену в rust-анализаторе. Он позволяет в простой форме определять правила переписывания синтаксиса. Мне давно хотелось иметь такую возможность, но я потратил целую вечность, чтобы узнать о ней. Почему? Потому что IDE не в состоянии ничему научить пользователей. Максимум, что мы получаем, — это несколько всплывающих меню о том, как использовать ту или иную функцию. Действительно, большинство программистов, похоже, изучают возможности IDE, наблюдая за другими программистами.

Должен быть способ, чтобы IDE наблюдала за тем, как вы пишете код, и предлагала способы ускорения работы. Может быть, она может сделать снимок вашего кода и заметить, что вы инвертировали оператор if, но не использовали кодовое действие invert-if-statement. В следующий раз, когда вы наведете курсор на оператор if, выведите всплывающую подсказку о том, что его можно инвертировать с помощью сочетания клавиш xyz.

Принцип кастомизации

Я начинал с использования emacs (забавный факт, я действительно пользователь emacs во втором поколении). Однако по мере того, как я начинал писать все больше и больше кода, я понял, что инструментарий IDE действительно делает мою жизнь намного проще, чем необходимость знать, как набрать заглавными буквами группу текста с помощью C-x C-u. Но иногда мне все же не хватает гибкости emacs. Например, трудно настраивать пользовательские действия. Или полностью изменить представление IDE о тексте или связках клавиш. Конечно, можно использовать плагины, но, как знает любой бывший пользователь emacs, плагины для привязки клавиш в emacs просто ужасны, потому что абстракция почти всегда не работает.

Я не утверждаю, что мы должны встроить в IDE интерпретатор LISP и замаскировать под действия IDE функции LISP, потому что это нелепо в квадрате. Но я очень рад появлению таких инструментов, как ast-grep, потому что они позволяют немного изменить настройки. Мне было бы интересно рассмотреть и другие идеи, например, плагины на WebAssembly.