Я и «умный» GUI в IDE

Updated: Этот пост написан до появления Copilot. Моё мнение о Copilot в отдельном посте.

В комментарии к модной типизации в Python мне обоснованно указали, что я не рассмотрел использование типов для помощи IDE. В частности, для автодополнения и подсказок.

Это действительно хороший повод для использования типов. Но в моей картине мира и в моём окружении разработчика подобные «умные» штуки находятся где-то на периферии полезности. Поэтому я о них периодически не помню.

Собственно году в 2010 я отказался от «умных» версий того же автодополнения и не жалею. В то же время, мои периодические порывы сменить Emacs на крутую современную IDE во многом вызваны как раз желанием проверить, не сделали ли наконец нормальный программистский CAD с действительно крутыми помощниками. Пока не сделали, так что сижу на Emacs :-)

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

На сколько я знаю, моя позиция не распространена, поэтому расскажу про её логику подробнее.

Польза от «умного» GUI

Тут всё довольно понятно. «Умный» интерфейс позволяет:

1. быстрее набирать код;
2. делать меньше ошибок в именах, параметрах функций и т.п.;
3. экономить время на поиске нужной функциональности в своём и чужом коде;
4. быстро переходить к документации, тестам, реализации;

Наверно ещё что-то позволяет, из области переходов и поиска; слышал про автоматическую вставку кода со StackOverflow :-)

Специфика моей работы

Исторически сложилось, что я работаю над довольно крупными, но не большими, долгосрочными проектами. На глаз, от 50к до 500к строк кода. Срок жизни таких проектов исчисляется годами. В общем-то, даже в основном репозитории Сказки сейчас 95000 строк кода без тестов и миграций.

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

Поэтому в большинстве случаев чревато писать код «на лету» — надо погружаться в контекст, в котором этот код существует и будет существовать. В частности, надо читать документацию, код, историю изменений, разговаривать с людьми.

Утрируя, может оказаться плохой идеей использовать первую функцию length, которую тебе высветило автодополнение. Через час после релиза выяснится, что эту функцию впилили два года назад в авральном режиме и она имеет сложность O(N) из расчёта на работу с контейнерами в 10 элементов, а не 10 миллионов, как оказалось через два года.

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

Поэтому я работаю в режиме split screen — смотрю сразу на два исходника (или на два места одного файла). Плюс, в фоне сидит ещё пара открытых файлов, на которые я могу переключиться не отрывая рук от клавиатуры — спасибо Emacs.

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

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

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

Как «умный» GUI накладывается на мою работу

Скорость редактирования кода практически никогда не является для меня заметным временным ограничением. Значительно больше времени я трачу на проектирование, чтение кода и документации.

Без подсказок параметров функций я определённо делаю больше ошибок опечаток. На сколько больше, не знаю, думаю не в разы. Однако тесты, фактом своей работы, выявят любую опечатку, которую найдёт и «умный» GUI. Поскольку редактирование кода — о-маленькое от затрачиваемого мной времени, время исправления опечаток не существенно. Есть нюанс с тем, что тесты не всегда работают быстро, но с задержкой тестов из-за массовых опечаток я сталкивался, наверно, только пару раз за карьеру. Чтобы это случилось, код надо писать в особенном состоянии ума :-)

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

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

Когда «умный» GUI может быть полезен

1. Когда приходится писать много однотипного кода.
2. Когда приходится часто переключаться между предметными областями.
3. Когда надо быстро начать писать код в незнакомом проекте.
4. Когда нет тестов.
5. Когда изучается новая технология.

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

Например, я сначала прочитал всю документацию по Julia и только потом начал что-то на ней делать. На сколько я знаю, такой подход нынче не в моде :-D

В общем, тоже не критично.

«Неумный» GUI

Отсутствие «умных» IDE-шных фич не означает, что я работаю аки в блокноте.

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

Я пользуюсь фичёй перехода к месту определения имени, но она работает с помощью grep, опять же, без синтаксического анализа.

У меня есть подсветка ошибок, но добавление описания типов не улучшило опыт её использования. А вот typeguard существенно улучшил работу тестов.

И так далее.

Резюме

Как говорил, я не против подсказок, помощников и прочего упрощения работы программистов. Упрощение нужно!

Но.

Усилия, которые мы тратим на минорные улучшения уже существующей функциональности, для меня выглядят как разработка машины Голдберга. Большая цена за минимум результата.

Нужна настоящая CAD система. Может быть с кардинально новым подходом к разработке (только не блок-схемы и прочая детская визуальщина). Нужен софт, который сделает с программированием то же, что CAD сделали с классической инженерией.

Однако создать такой софт не просто. CAD-ы направлены на устранение рутины из работы инженеров. Рутины у них было много, так как они работали руками. У программистов рутины значительно меньше.

Точнее нет, рутины не меньше, но эта рутина высокоуровневая. Её сложно выделить и ещё сложнее автоматизировать.

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

И чем более уникальный код вы пишете, тем меньше вам будут полезны «умные» помощники по сравнению с «неумными».