Редакторы и IDE: карта трека и как выбирать инструмент

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

Этот трек — попытка обсудить среду обитания без религии. Мы разберём, как редакторы устроены внутри, что изменилось после появления Language Server Protocol, сколько на самом деле стоит переход с одного инструмента на другой, и как принять решение, о котором вы не пожалеете через полгода. Практики будет много: реальные .vimrc, init.lua, settings.json, конфигурация tmux и разбор публичного репозитория dotfiles.

Начнём с неудобного вопроса.

Влияет ли редактор на продуктивность вообще?

Честный ответ: влияет, но не так и не настолько, как принято думать.

Работа программиста — это цепочка петель обратной связи разной длительности. Нажали клавишу — увидели символ (десятки миллисекунд). Прыгнули к определению функции — увидели её тело (сотни миллисекунд). Сохранили файл — получили ошибку типов (секунда). Запустили тест (десять секунд). Собрали проект (минута). Дождались CI (десять минут). Выкатили и посмотрели метрики (часы).

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

1. Если у вас 12-минутный CI и трёхминутная инкрементальная сборка, менять редактор бессмысленно. Выигрыш утонет в шуме. Сначала чините правую часть шкалы.
2. Если тулчейн быстрый, редактор внезапно становится узким местом. На проекте с Go или Rust, где go build занимает секунду, заминка редактора на 300 мс при автодополнении — это уже ощутимая доля цикла.

Ещё одна честная поправка: единственное строгое эмпирическое утверждение, которое десятилетиями воспроизводится в исследованиях производительности программистов, — разброс между людьми на порядок больше разброса между инструментами. Классика жанра — измерения Сакмана 1968 года и последующие обсуждения у Демарко и Листера в Peopleware; величина «10x» многократно оспаривалась методологически, но сам факт огромной дисперсии не оспаривает почти никто. Редактор — рычаг второго порядка. Полезный, но второго.

Зачем тогда трек на одиннадцать статей? Потому что рычаги второго порядка работают каждый день много лет, и потому что глубокое владение инструментом снимает микротрение, которое незаметно съедает внимание. Разница не в скорости печати, а в том, сколько раз за день вы теряете мысль, пока ищете, где определена функция.

Анатомия редактора: пять слоёв

Чтобы сравнивать редакторы осмысленно, надо понимать, из чего они состоят. Почти любой современный редактор разбирается на пять слоёв.

Слой 1. Ядро: буферы и текст. Как хранится редактируемый текст в памяти. Наивный массив строк рассыпается на файле в сотни мегабайт. Классические решения — gap buffer (Emacs), rope и piece table (VS Code использует piece tree — см. разбор от команды VS Code). Отсюда же undo-дерево, кодировки и обработка длинных строк. Слой невидимый, пока не откроете лог на 2 ГБ или минифицированный бандл — тогда он становится единственным, что имеет значение.

Слой 2. Лексика: подсветка и структура. Двадцать лет здесь правили regex-грамматики формата TextMate — их унаследовали Sublime Text, Atom и VS Code. Они дёшевы и приблизительны: подсветка в них — это последовательность регулярок, а не понимание кода. Современная альтернатива — Tree-sitter: инкрементальный GLR-парсер, который строит настоящее конкретное синтаксическое дерево, обновляет его за время, пропорциональное размеру правки, и не ломается на синтаксически некорректном коде (а код в редакторе некорректен почти всегда — вы же его прямо сейчас печатаете). Tree-sitter дал не только подсветку, но и структурную навигацию, умные текстовые объекты и надёжное сворачивание блоков.

Слой 3. Семантика: LSP. Знание типов, разрешение имён, поиск ссылок, переименование, code actions. Исторически это была вотчина IDE и главная причина их существования. С 2016 года — стандартизованный протокол, к которому мы вернёмся отдельно.

Слой 4. Исполнение. Отладка (стандартизована как Debug Adapter Protocol), тест-раннеры, задачи сборки, встроенный терминал. Здесь разрыв между IDE и редакторами всё ещё заметен: DAP покрывает базовый сценарий, но условные точки останова по данным, профилировщики и инспекция кучи в JetBrains и Visual Studio остаются заметно глубже.

Слой 5. Оболочка. Клавиатурная модель (модальная или аккордная), палитра команд, управление окнами и сессиями, темы. Именно этот слой люди имеют в виду, когда говорят «я привык к редактору», и именно он дороже всего переучивается: моторная память формируется месяцами.

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

Как мы сюда пришли

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

Три перелома в этой линии важнее остальных.

Первый — модальность vi. Билл Джой писал vi на терминале с модемом 300 бод: примерно 30 символов в секунду, то есть перерисовка экрана занимала секунды. В таких условиях экономия нажатий — не эстетика, а необходимость. Модальность решала и вторую проблему: на терминалах не было надёжных модификаторов, а команда из одной буквы работала везде. Ограничение железа стало языком редактирования, который пережил своё железо на полвека.

Второй — Emacs как программируемая среда. Emacs решил задачу иначе: не экономить нажатия, а сделать сам редактор расширяемым на полноценном языке (Emacs Lisp), где любая команда — функция, любая функция переопределяема, а состояние доступно из кода. Отсюда org-mode, почтовые клиенты и всё остальное. Идея «редактор как среда исполнения» победила: у VS Code она реализована на TypeScript, у Neovim — на Lua.

Третий и самый недооценённый — LSP. О нём отдельно.

LSP: почему после 2016 года спор изменился

До 2016 года сравнение «редактор против IDE» было простым и не в пользу редакторов. IDE знала ваш код: типы, ссылки, иерархию классов. Редактор знал текст. Чтобы получить автодополнение по типам в N редакторах для M языков, кто-то должен был написать N × M интеграций — и никто не писал.

Microsoft, разрабатывая VS Code, столкнулась с этой же комбинаторикой и вынесла семантику в отдельный процесс с JSON-RPC протоколом. Стало N + M: каждый редактор реализует клиента один раз, каждый язык — сервер один раз.

Обратите внимание на три детали, которые объясняют повседневное поведение инструментов.

Диагностика приходит push-ом, а не по запросу. Сервер сам решает, когда прислать ошибки. Отсюда эффект «подчёркивание отстаёт от курсора»: вы уже исправили опечатку, а красная волна ещё висит. Это не баг редактора, это протокол.

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

Индекс строится в отдельном процессе. Первые секунды (для больших монорепозиториев — минуты) после открытия проекта семантики просто нет. Одинаково верно и для gopls, и для rust-analyzer, и для IntelliJ с её собственным индексом.

Что LSP не унифицировал и где IDE сохранили преимущество: сложные многошаговые рефакторинги (extract interface, change signature с обновлением всех вызовов), знание фреймворков (навигация из шаблона Spring в бин, из Rails-роута в контроллер), кросс-языковая навигация внутри одного проекта, инспекции на основе анализа потока данных. Протокол описывает rename и codeAction, но не обязывает сервер быть умным.

Итог для практики: разрыв в базовой семантике между хорошо настроенным Neovim и JetBrains IDE в 2026 году невелик. Разрыв в тяжёлых рефакторингах и во «встроенном знании фреймворка» сохраняется.

Пространство выбора

Разложим основные инструменты по двум осям: глубина семантики и знаний о проекте (по вертикали) и лёгкость — скорость запуска, потребление памяти, отзывчивость (по горизонтали).

Правый верхний угол в 2026 году перестал быть пустым — туда переехали Neovim с настроенным LSP, Zed и Helix. Это и есть главное изменение последнего десятилетия: раньше приходилось выбирать между умом и лёгкостью, теперь — гораздо реже.

Но у лёгкости правого верхнего угла есть цена, которую редко называют вслух: вы становитесь системным администратором своего редактора. Neovim с LSP, Treesitter, автодополнением и отладчиком — это 400–900 строк вашего Lua, которые ломаются при обновлениях плагинов. IntelliJ — это ноль строк конфигурации и работающий отладчик из коробки. Это не аргумент против Neovim, это статья расходов, которую надо внести в смету.

Критерии выбора и их веса

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

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

Дерево решений, если нужен быстрый ответ:

Сколько стоит переход

Разговор о смене редактора почти всегда ведётся без цифр. Давайте с цифрами.

Переход на модальный редактор с нуля — это примерно такая кривая по опыту людей, которые её проходили и описывали (см., например, классический тред Your problem with Vim is that you don’t grok vi):

Ключевая честность: 115% на редактировании — это не 115% на разработке. Собственно набор и правка текста занимают у среднего разработчика заметно меньше половины времени; остальное — чтение, размышление, отладка, обсуждение. Прирост 15% на трети деятельности — это порядка 5% общей продуктивности. За две-четыре недели просадки.

Окупается ли? Считайте так:

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

Отдельная стратегия, которая почти всегда выигрышна: освоить vi-режим внутри того редактора, которым вы уже пользуетесь. VS Code имеет расширение VSCodeVim и более быстрый vscode-neovim, JetBrains — IdeaVim, Zed и Helix поддерживают модальность нативно. Вы получаете модель редактирования, не теряя отладчик и рефакторинги. Для большинства людей это оптимальная точка.

Пять мифов, которые стоит демонтировать

«Vim делает тебя быстрее». Vim делает быстрее редактирование текста. Если бутылочное горлышко — понимание чужого кода или отладка гонки в проде, Vim не поможет. Модальность — это про экономию движений, а не про мышление.

«IDE тормозят». IntelliJ на проекте в 200 тысяч строк на современной машине с 4 ГБ выделенной кучи работает без заметных задержек. Тормозит она на монорепозиториях с миллионами строк, при индексации сгенерированного кода и на машинах с 8 ГБ RAM. Формулировка «тормозит» без указания размера проекта бессодержательна.

«Electron — это медленно». Electron даёт большой стартовый расход памяти (VS Code — типично 300–600 МБ на окно с расширениями) и медленный холодный старт. Но в установившемся режиме основная задержка ввода в VS Code — не Electron, а плагины и медленные language-серверы. Проверяется командой Developer: Startup Performance и профилировщиком расширений; чаще всего виноваты два-три установленных «на всякий случай» плагина.

«Настоящие программисты пользуются X». Кен Томпсон пользовался ed. Джон Кармак много лет работал в Visual Studio и публично хвалил её отладчик. Линус Торвальдс написал собственный форк MicroEmacs. Корреляции между инструментом и качеством инженера нет.

«Мне не нужен Vim, я работаю в GUI». Пока вы не окажетесь в SSH-сессии на упавшем проде, где надо поправить один параметр в конфиге, и единственное, что там есть, — vi. Базовые 20 команд — это не выбор редактора, это часть системной грамотности. Ровно об этом следующая статья трека.

Гигиена окружения: dotfiles

Как только вы вкладываетесь в настройку инструмента, у вас появляется актив — конфигурация, которую нельзя потерять и хочется переносить между машинами. Отсюда практика dotfiles: конфиги живут в git-репозитории, а в домашнюю директорию попадают симлинками или скриптом установки.

В качестве живого примера в этом треке мы разбираем публичный репозиторий the-homeless-god/Dotfiles. Его верхний уровень устроен так: каталоги configs/, scripts/, ci/, docs/, demo/, а также Makefile, Dockerfile и docker-compose.yml. Внутри configs/ лежат собственно конфигурации — .vimrc, .zshrc, .gitconfig, .editorconfig, .alacritty.toml, .lfrc, tmux.sh, tools.json, каталоги .config/ и fonts/.

Три архитектурных решения этого репозитория стоит отметить уже сейчас, потому что они типичны для зрелых dotfiles:

1. Разделение «что» и «как». Конфиги отдельно (configs/), логика установки отдельно (scripts/, Makefile). Это позволяет читать конфиг, не продираясь через bash.
2. Декларативный список инструментов. tools.json — это перечисление того, что должно быть установлено, отдельно от кода установки. Тот же принцип, что у Brewfile или NixOS-конфигурации: состояние описано данными, а не последовательностью команд.
3. Воспроизводимость через контейнер. Наличие Dockerfile и docker-compose.yml означает, что установку можно прогнать в чистом окружении, не ломая свою машину. Это ровно то, чего не хватает 95% dotfiles-репозиториев: их авторы никогда не проверяли, работает ли их установщик на пустой системе.

Детальный разбор .vimrc и структуры .config/ будет в статье про Neovim и конфигурацию, а вопросы синхронизации окружения между машинами — в статье про терминальный workflow.

Минимальный работающий скелет, если вы начинаете свои dotfiles с нуля:

#!/usr/bin/env bash
# ~/dotfiles/install.sh — простейший установщик через симлинки.
# Идея: репозиторий — источник истины, домашняя директория — набор ссылок на него.
set -euo pipefail

DOTFILES_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
BACKUP_DIR="$HOME/.dotfiles-backup/$(date +%Y%m%d-%H%M%S)"

link() {
    local src="$DOTFILES_DIR/$1"
    local dst="$HOME/$2"

    # Уже правильный симлинк — ничего не делаем (идемпотентность).
    if [[ -L "$dst" && "$(readlink "$dst")" == "$src" ]]; then
        echo "ok    $2"
        return
    fi

    # Существующий файл не удаляем молча, а откладываем в бэкап.
    if [[ -e "$dst" || -L "$dst" ]]; then
        mkdir -p "$BACKUP_DIR/$(dirname "$2")"
        mv "$dst" "$BACKUP_DIR/$2"
        echo "backup $2 -> $BACKUP_DIR/$2"
    fi

    mkdir -p "$(dirname "$dst")"
    ln -s "$src" "$dst"
    echo "link  $2"
}

link configs/.vimrc              .vimrc
link configs/.zshrc              .zshrc
link configs/.gitconfig          .gitconfig
link configs/.editorconfig       .editorconfig
link configs/.config/nvim        .config/nvim
link configs/.config/tmux        .config/tmux

Три правила, которые спасают от боли:

• Идемпотентность. Скрипт должен безопасно запускаться десять раз подряд.
• Никогда не удалять чужие файлы молча. Только бэкап.
• Секреты не в репозитории. Токены и рабочие email — в отдельном ~/.gitconfig.local, который подключается через [include] path = ~/.gitconfig.local и не коммитится.

Как проверить редактор перед тем, как в него вкладываться

Не верьте бенчмаркам из интернета — они меряют чужие проекты. Проверьте на своём. Разумный протокол занимает полчаса.

# 1. Холодный старт на РЕАЛЬНОМ проекте, а не на пустой папке.
#    Три прогона, берём медиану.
time code --wait /path/to/your/repo     # VS Code
time nvim /path/to/your/repo/src/main.go
# JetBrains замеряется по «Indexing finished» в строке состояния.

# 2. Память в установившемся режиме, через 5 минут работы.
ps -o rss=,comm= -p $(pgrep -d, -f 'nvim|code|idea') | awk '{printf "%.0f МБ\t%s\n", $1/1024, $2}'

# 3. Задержка семантики: сколько идти до определения символа
#    в файле, который открыт впервые. Секундомер, честно, руками.

# 4. Поведение на патологическом файле — генерируем 100 МБ.
python3 -c "
open('/tmp/big.txt','w').writelines(f'line {i} ' + 'x'*200 + '\n' for i in range(500000))
"
time vim /tmp/big.txt      # обычно мгновенно
# то же самое в кандидате — многие Electron-редакторы здесь показывают характер

# 5. Реальная задача. Возьмите свой вчерашний коммит и повторите его
#    в новом инструменте от начала до конца, включая запуск тестов и git.

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

Типичные ошибки

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

Установка тридцати расширений в первый день. Каждое расширение — это процесс, память и потенциальный источник задержки ввода. В VS Code запустите Developer: Show Running Extensions и посмотрите на колонку времени активации; обычно два-три плагина отвечают за большую часть тормозов.

Настройка вместо работы. Известный анти-паттерн: человек полгода полирует конфиг Neovim и за это время не написал ни строчки продуктового кода. Полезное правило — бюджет: не больше часа настройки в неделю, и только под конкретную боль, которую вы записали.

Смена инструмента прямо перед дедлайном. Просадка на 30% в первую неделю — это факт, а не пессимизм. Меняйте инструмент в спокойный период.

Отказ учить встроенные горячие клавиши. Люди годами кликают мышью «найти использования», хотя это одно сочетание. Практика, которая окупается за неделю: раз в день узнавайте одну новую комбинацию и сознательно используйте её десять раз.

Игнорирование настроек проекта. .editorconfig, конфиг форматтера, .vscode/settings.json в репозитории — это то, что избавляет команду от диффов, состоящих из перестановки пробелов. Стоит один вечер, экономит бесконечные споры на ревью.

Карта трека

Как проходить трек в зависимости от вашей ситуации:

Полный список статей трека:

• vi и Vim: модальность, основы, движения и первые 20 команд
• Продвинутый Vim: регистры, макросы, текстовые объекты, буферы, окна, quickfix
• Neovim и конфигурация: Lua, LSP, Treesitter, плагины, разбор реальных dotfiles
• Emacs: философия, org-mode, elisp и почему он всё ещё жив
• VS Code: архитектура, расширения, отладка, remote и devcontainers
• JetBrains IDE: индексация, рефакторинги, инспекции, когда они окупаются
• Eclipse, NetBeans и наследие: где они остались и почему
• Zed, Sublime Text, Atom-подобные и новая волна редакторов
• Терминальный рабочий процесс: tmux, оболочка, dotfiles, синхронизация окружения
• Сравнение всех редакторов и IDE: критерии, таблица, сценарии выбора

Трек хорошо ложится рядом с операционными системами (процессы, файловые дескрипторы, терминалы — всё это про то, как редактор живёт в системе) и с DevOps (воспроизводимые окружения, контейнеры, автоматизация установки).

Мини-итог

• Редактор влияет на левую треть шкалы обратной связи: от нажатия клавиши до диагностики. Если правая треть (сборка, тесты, CI) медленная, начинайте с неё.
• Современный редактор — это пять слоёв: буфер, лексика (Tree-sitter), семантика (LSP), исполнение (DAP), оболочка. Чем выше слой, тем дороже его менять.
• LSP в 2016 году сделал семантику переносимой между редакторами и почти закрыл главный разрыв с IDE. Не закрыл: тяжёлые рефакторинги, знание фреймворков, глубокая отладка.
• Правый верхний угол «умный и быстрый» перестал быть пустым, но платой за него стала роль администратора собственного редактора.
• Переход на модальное редактирование даёт порядка 15% на редактировании и порядка 5% на разработке в целом, ценой двух-четырёх недель просадки. Компромисс без просадки — vi-режим внутри вашей текущей IDE.
• Выбирайте по трём главным критериям: поддержка вашего языка, скорость на вашем размере проекта, отладка. Остальное — тонкая настройка.
• Настройка — это инвестиция с бюджетом. Час в неделю, только под записанную боль, конфиг в git.

Источники

• Language Server Protocol Specification — первоисточник по LSP.
• Debug Adapter Protocol — то же для отладки.
• Tree-sitter documentation — инкрементальный парсинг.
• Max Brunsfeld, Tree-sitter: a new parsing system for programming tools — доклад автора Tree-sitter (Strange Loop 2018).
• Text Buffer Reimplementation — как VS Code перешёл на piece tree.
• Bill Joy, интервью об истории vi — про 300 бод и модальность.
• Richard Stallman, EMACS: The Extensible, Customizable Display Editor — оригинальная статья 1981 года.
• Tom DeMarco, Timothy Lister, Peopleware: Productive Projects and Teams — о дисперсии производительности и о среде.
• the-homeless-god/Dotfiles — публичный репозиторий dotfiles, который мы разбираем в треке.
• dotfiles.github.io — каталог практик и инструментов управления dotfiles.
• EditorConfig — способ договориться о форматировании поверх любых редакторов.

Что дальше

Начнём с фундамента, который пригодится независимо от вашего основного инструмента: модальное редактирование, режимы, движения и тот минимум, который позволяет уверенно чувствовать себя в любой SSH-сессии.

vi и Vim: модальность, основы, движения и первые 20 команд