Сравнение всех редакторов и IDE: критерии, таблица, сценарии выбора

Девять статей трека мы разбирали инструменты по одному: как устроена модальность Vim, что происходит внутри индексатора IntelliJ, почему VS Code разнесён на процессы, зачем Emacs свой Lisp. Теперь пора сделать то, ради чего люди обычно и открывают такие тексты, — положить всё рядом и выбрать.

Проблема в том, что 95% сравнений редакторов бесполезны, и по вполне понятной причине. Они сравнивают инструменты, а сравнивать надо связки: инструмент плюс язык плюс размер проекта плюс способ работы. «VS Code быстрее IntelliJ» — утверждение без единицы измерения. Быстрее в чём: в холодном старте, в отклике на клавишу, в поиске всех использований метода в монорепозитории на четыре миллиона строк? На первом VS Code выигрывает вчистую, на третьем проигрывает так, что вопрос закрыт.

Эта статья — попытка сделать сравнение воспроизводимым: сначала методика, потом измерения, потом таблицы, потом сценарии. И отдельно — большой честный раздел о том, что измерить нельзя, но что решает исход чаще, чем всё измеримое вместе взятое.

Три группы критериев: возможности, издержки, риски

Начнём с таксономии. Почти все критерии, по которым люди выбирают редактор, укладываются в три группы, и путаница между ними — источник половины бессмысленных споров.

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

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

Что действительно можно измерить и как

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

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

#!/usr/bin/env bash
# bench-editors.sh — грубое, но воспроизводимое сравнение старта редакторов.
# Требуется hyperfine: https://github.com/sharkdp/hyperfine
set -euo pipefail

PROJECT="${1:-$HOME/work/main-repo}"   # проект, на котором реально работаете
FILE="${2:-src/main.go}"               # файл, который открываете чаще всего

echo "== Холодный старт: терминальные редакторы =="
# --warmup 3 отсекает влияние дискового кэша: сравниваем установившийся режим
hyperfine --warmup 3 --runs 10 \
  "vim -c ':q' $PROJECT/$FILE" \
  "nvim --headless -c ':q'" \
  "nvim -c ':q' $PROJECT/$FILE" \
  "hx --version"                        # helix стартует так быстро, что мерить надо иначе

echo
echo "== Детализация старта Neovim по плагинам =="
# --startuptime пишет пофазный отчёт: видно, какой плагин съедает бюджет
nvim --startuptime /tmp/nvim-start.log -c ':q' "$PROJECT/$FILE"
sort -k2 -n -r /tmp/nvim-start.log | head -20

echo
echo "== Память в установившемся режиме =="
# запустите редакторы вручную, дайте им проиндексироваться, потом:
for proc in "Code Helper" idea java nvim emacs zed; do
  ps -eo rss=,comm= | grep -i "$proc" | awk '{sum += $1} END {if (sum) printf "%-16s %6.0f МБ\n", "'"$proc"'", sum/1024}'
done

echo
echo "== Открытие большого файла =="
# генерируем 200 МБ текста и смотрим, кто выживет
python3 -c "open('/tmp/big.log','w').write(('x'*120+'\n')*1700000)"
time vim -c ':q' /tmp/big.log
time nvim -c ':q' /tmp/big.log
echo "VS Code и IDE проверьте вручную: они переходят в урезанный режим на больших файлах"

Три предупреждения по методике, без которых цифры будут враньём:

1. Первый запуск не считается. Дисковый кэш, JIT-прогрев, ленивая распаковка ресурсов. Отсюда --warmup 3.
2. Сравнивайте одинаковую функциональность. nvim без плагинов против IntelliJ — это не сравнение редакторов, это сравнение блокнота с IDE. Честный замер: Neovim с настроенным LSP, Treesitter и автодополнением против IDE с теми же возможностями.
3. Отклик на клавишу не измеряется секундомером. Нужен Typometer Павла Фатина (статья про latency в редакторах — до сих пор лучший разбор темы) или съёмка экрана на 240 кадрах в секунду.

Профили вместо рейтингов

Главная ловушка сравнительных таблиц — соблазн сложить галочки и объявить победителя. Так не работает: инструменты не упорядочены по одной шкале, у них разные формы.

Обратите внимание: ни одна фигура не содержит другую целиком. Если бы содержала, спор закончился бы сам собой ещё в нулевые. Тяжёлая IDE выигрывает по семантике и отладке и проигрывает по скорости и работе через SSH; терминальный редактор — ровно наоборот; VS Code сидит в середине почти по всем осям, и в этом одновременно его сила и его потолок.

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

Взвешенная оценка: считаем честно

Если всё же хочется числа — считайте его правильно: с явными весами, которые вы написали до того, как увидели результат. Это защищает от подгонки под уже принятое решение.

"""Взвешенная оценка редакторов под конкретную ситуацию.

Смысл не в том, чтобы получить «объективный» рейтинг — его не существует.
Смысл в том, чтобы веса были записаны ДО подсчёта и обсуждались отдельно от оценок.
"""
from dataclasses import dataclass

# Веса под конкретную ситуацию: бэкенд на Go, монорепозиторий, много работы по SSH.
# Сумма весов не обязана равняться единице — важны только их отношения.
WEIGHTS = {
    "семантика":      3,   # переход к определению, поиск использований
    "скорость":       3,   # монорепозиторий, тяжёлая IDE ощутимо проседает
    "отладка":        1,   # у нас в основном логи и тесты, отладчик — редко
    "расширяемость":  1,
    "простота_старта": 2,  # в команде есть джуны, онбординг важен
    "ssh":            3,   # половина работы на удалённых машинах
}

# Оценки 0–5. Проставляйте их ПОСЛЕ двух недель реальной работы, а не по обзорам.
SCORES = {
    "IntelliJ IDEA":  {"семантика": 5, "скорость": 2, "отладка": 5,
                       "расширяемость": 3, "простота_старта": 5, "ssh": 3},
    "VS Code":        {"семантика": 4, "скорость": 3, "отладка": 4,
                       "расширяемость": 4, "простота_старта": 5, "ssh": 5},
    "Neovim + LSP":   {"семантика": 4, "скорость": 5, "отладка": 3,
                       "расширяемость": 5, "простота_старта": 1, "ssh": 5},
    "Zed":            {"семантика": 4, "скорость": 5, "отладка": 3,
                       "расширяемость": 2, "простота_старта": 4, "ssh": 3},
}

@dataclass
class Result:
    name: str
    total: float
    weakest: str          # ось, где инструмент проваливается сильнее всего по весу

def evaluate(name: str, scores: dict[str, int]) -> Result:
    total = sum(scores[k] * w for k, w in WEIGHTS.items())
    # «Больно» там, где низкая оценка совпала с высоким весом
    weakest = min(WEIGHTS, key=lambda k: scores[k] * WEIGHTS[k])
    return Result(name, total / sum(WEIGHTS.values()), weakest)

for name, scores in sorted(SCORES.items(),
                           key=lambda kv: -evaluate(*kv).total):
    r = evaluate(name, scores)
    print(f"{r.name:<16} {r.total:.2f}   слабое место: {r.weakest}")

# Пример вывода для этих весов:
# VS Code          4.15   слабое место: отладка
# Neovim + LSP     4.00   слабое место: простота_старта
# IntelliJ IDEA    3.62   слабое место: скорость
# Zed              3.77   слабое место: расширяемость

Сложность подсчёта — O(n·k) по времени при n инструментах и k критериях, что при n ≈ 10 и k ≈ 8 несущественно. Существенно другое: колонка «слабое место» полезнее колонки с итоговым баллом. Итоговый балл усредняет, а вас убьёт не среднее, а провал.

Большая матрица: возможности

Теперь собственно сравнение. Оценки — экспертные, шкала 0–5, состояние на середину 2026 года. Там, где ответ зависит от языка, это отмечено явно.

Что стоит прочитать в этой таблице внимательно:

Рефакторинги — единственная колонка, где разрыв не закрылся. LSP выровнял переход к определению и автодополнение почти для всех, но textDocument/rename в языковом сервере и «Change Signature» в IntelliJ — это разные по надёжности вещи. Подробности были в статье про JetBrains (https://courses.digitable.life/post/editors/06-jetbrains/): IDE держит собственную модель кода, включая незакоммиченные изменения и связи через фреймворки, и умеет откатывать рефакторинг целиком. Языковой сервер обычно предложит переименование в рамках того, что он проиндексировал, и молча не тронет строковый литерал в конфиге.

Отладка — вторая незакрытая колонка. DAP сделал возможным отладку почти везде, но разница между «работает после часа настройки конфигурации nvim-dap» и «поставил точку останова мышкой» велика, и для человека, который отлаживает по десять раз в день, она решающая.

Большие файлы — колонка, которую все игнорируют, пока не упрутся. Открыть гигабайтный лог в Electron-редакторе или в IDE на JVM — способ подвесить машину. Vim и Sublime здесь вне конкуренции, и это одна из причин, почему навык vi полезен независимо от основного инструмента.

Большая матрица: издержки и риски

Цены на лицензии меняются, обязательно сверяйтесь с прайс-листом JetBrains и лицензированием Visual Studio на момент принятия решения — здесь они даны только для порядка величин.

Столбец «обслуживание в год» — самый недооценённый. Это часы на починку после обновлений, на разбирательство с внезапно отвалившимся языковым сервером, на миграцию менеджера плагинов. Для самосборного Neovim цифра 10–20 часов в год — не пессимизм, а средний результат честного учёта: экосистема плагинов живая, ломающие изменения случаются.

Соберём это в накопленную картину за два года.

Разница между «поставил IDE и работаешь» и «собрал Neovim под себя» за два года — порядка шестидесяти часов, полторы рабочие недели. Это не аргумент против Neovim. Это статья расходов, которую надо внести в смету и сопоставить с выигрышем — а выигрыш, как мы честно посчитали в обзоре трека (https://courses.digitable.life/post/editors/00-overview/), составляет единицы процентов общей продуктивности, но накапливается годами и не привязан к работодателю.

Что измерить нельзя, но что решает

Теперь самое важное. Ни одна цифра выше не объясняет, почему люди годами держатся за инструмент, проигрывающий по таблице. Объясняют три неизмеримые вещи.

Мышечная память. Через несколько лет использования инструмента ваши руки знают сотни сочетаний, которые вы не смогли бы перечислить вслух. Смена инструмента обнуляет этот капитал и заменяет автоматизм сознательным усилием — то есть тратит именно тот ресурс, который нужен для собственно программирования. Классическое объяснение того, почему это дорого, — Fitts и Hick вместе с моделью GOMS из работ Card, Moran и Newell: время операции складывается из моторного, перцептивного и когнитивного компонентов, и переучивание бьёт по всем трём сразу.

Ощущение контроля. Часть людей испытывает физический дискомфорт, когда не понимает, что делает их инструмент. Для них Emacs, где любую функцию можно открыть по C-h f и прочитать исходник, — не удобство, а условие спокойной работы. Другая часть людей ровно так же не хочет знать, как устроен их редактор, и для них любая конфигурация — налог. Обе позиции разумны, спорить о них бессмысленно, но учитывать при выборе — обязательно.

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

Как менялась картина: почему старые сравнения устарели

Многие бытующие мнения о редакторах верны для 2013 года и неверны для 2026.

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

1. До 2016 года «редактор против IDE» было сравнением возможностей. После — сравнением упаковки. Тот же gopls работает и в VS Code, и в Neovim, и в Emacs, и в Helix. Различается обвязка: насколько удобно, насколько из коробки, насколько предсказуемо.
2. Аргумент «Electron тормозит» стоит проверять, а не повторять. Проверяется он командой Developer: Startup Performance в VS Code, и чаще всего виноват не Electron, а три расширения, поставленные «на всякий случай».
3. Ассистенты на LLM — новая ось, по которой инструменты уже расходятся. Здесь картина меняется быстрее, чем успевает устаревать статья, поэтому конкретных оценок в таблицах выше по ней намеренно нет: любые цифры протухнут за квартал.

Жизненный цикл отношений с инструментом

Выбор редактора — не событие, а процесс, и у него есть предсказуемые фазы. Понимание того, в какой вы фазе, помогает не принимать «мне скучно» за «инструмент плох».

Состояние «Дрейф» заслуживает отдельного упоминания, потому что оно маскируется под продуктивность. Признак простой и проверяемый: посмотрите git log вашего репозитория с dotfiles за последний месяц и сравните число коммитов с числом реальных проблем, которые эти коммиты решили. Если коммитов вдвое больше — вы дрейфуете.

Сценарии выбора

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

Отдельно — стратегия, которая почти всегда выигрышна и которую мы уже упоминали в обзоре: модальное редактирование внутри тяжёлой IDE. IdeaVim в JetBrains, vscode-neovim в VS Code, нативная модальность в Zed и Helix. Вы получаете грамматику редактирования из статьи https://courses.digitable.life/post/editors/01-vi-and-vim-basics/, не теряя отладчик и рефакторинги. Для большинства людей это оптимальная точка компромисса, и она почти не обсуждается в спорах, потому что не даёт повода для спора.

Командное решение: что стандартизировать, а что нет

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

Ключевая мысль: почти все реальные проблемы, из-за которых команды хотят стандартизировать редактор, решаются стандартизацией не редактора, а артефактов. Вот минимальный набор, который снимает 90% боли и оставляет людям свободу.

.editorconfig в корне репозитория — понимают все инструменты трека, включая Vim с плагином, Emacs, VS Code и JetBrains из коробки:

# .editorconfig — договорённость о форматировании поверх любых редакторов
# Спецификация: https://editorconfig.org/
root = true

[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true
indent_style = space
indent_size = 4

[*.{js,ts,tsx,json,yml,yaml}]
indent_size = 2

[*.go]
indent_style = tab          # gofmt настаивает на табах, спорить бессмысленно

[Makefile]
indent_style = tab          # make физически не умеет иначе

[*.md]
trim_trailing_whitespace = false   # два пробела в конце — это перенос строки

Проверка формата в CI, а не в редакторе. Это ключ ко всей стратегии: если формат проверяется автоматически, то чем именно человек его наводит — не имеет значения.

# .github/workflows/format.yml — формат проверяется в CI, а не в чужой голове
name: format
on: [pull_request]

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with:
          go-version: '1.23'

      - name: gofmt
        run: |
          # Никаких «у меня локально по-другому»: единственный источник истины — CI
          unformatted=$(gofmt -l .)
          if [ -n "$unformatted" ]; then
            echo "Не отформатировано:"; echo "$unformatted"; exit 1
          fi

      - name: линтер
        run: go vet ./...

Рекомендованный, но не обязательный набор для VS Code — файл кладётся в репозиторий, и VS Code сам предложит установить расширения при открытии проекта:

// .vscode/extensions.json — рекомендации, а не принуждение
{
  "recommendations": [
    "golang.go",
    "editorconfig.editorconfig",
    "eamodio.gitlens"
  ],
  // Расширения, которые в этом проекте мешают: конфликтуют с gofmt
  "unwantedRecommendations": [
    "ms-vscode.cpptools"
  ]
}

// .vscode/settings.json — только то, что касается ПРОЕКТА, а не вкусов человека
{
  "editor.formatOnSave": true,
  "[go]": {
    "editor.defaultFormatter": "golang.go",
    "editor.codeActionsOnSave": { "source.organizeImports": "explicit" }
  },
  // Индексация node_modules и артефактов сборки — главный источник тормозов
  "files.watcherExclude": {
    "**/node_modules/**": true,
    "**/vendor/**": true,
    "**/.git/objects/**": true
  },
  "search.exclude": { "**/vendor": true, "**/dist": true }
}

И воспроизводимое окружение, которое делает вопрос «а у меня какая версия Go?» несуществующим:

// .devcontainer/devcontainer.json — одинаковый тулчейн у всех, редактор — любой
{
  "name": "backend",
  "image": "mcr.microsoft.com/devcontainers/go:1.23",
  "features": {
    "ghcr.io/devcontainers/features/docker-in-docker:2": {}
  },
  // Секция customizations игнорируется другими редакторами — и это нормально:
  // тем, кто пришёл с Neovim, достаточно того же контейнера без этой части.
  "customizations": {
    "vscode": {
      "extensions": ["golang.go", "editorconfig.editorconfig"]
    }
  },
  "postCreateCommand": "go mod download && go install github.com/go-delve/delve/cmd/dlv@latest"
}

Про терминальную часть этого набора — tmux, оболочку, синхронизацию dotfiles между машинами — подробно в статье https://courses.digitable.life/post/editors/09-terminal-and-workflow/. Про то, как публичные dotfiles устроены на практике (структура, менеджер симлинков, разделение машинно-зависимых частей), — в разборе конфигурации из https://courses.digitable.life/post/editors/03-neovim-and-config/.

Протокол двухнедельного испытания

Если после всех таблиц вы всё-таки собрались менять инструмент — не делайте это «с понедельника навсегда». Сделайте эксперимент с заранее объявленным критерием успеха.

Неделя 0, подготовка (2 часа). Запишите на бумаге три вещи: пять операций, которые вы выполняете чаще всего; текущее время выполнения каждой в старом инструменте; порог, ниже которого эксперимент считается провальным. Без записанного заранее порога вы задним числом объявите успехом что угодно.

Дни 1–3, выживание. Только базовое: открыть файл, отредактировать, сохранить, найти текст, закоммитить. Никаких плагинов сверх минимума. Задача — не быть продуктивным, а понять, не отторгает ли вас инструмент физически.

Дни 4–7, рабочая нагрузка. Настоящие задачи, но не срочные. Здесь появляется LSP, поиск по проекту, навигация. Ведите список «что бесит» — не чините его сразу, копите.

Дни 8–12, чинка. Теперь берите список и закрывайте позиции по одной, начиная с самой частой. Здесь же — проверка отладки на реальном баге. Если отладка не заработала за один вечер, это сильный сигнал.

Дни 13–14, решение. Замерьте те же пять операций. Сравните с записанными цифрами и с записанным порогом.

#!/usr/bin/env bash
# trial-checklist.sh — чек-лист испытания: прогоните вручную, отметьте, что не закрылось.
cat <<'EOF'
[ ] открыть проект и дождаться готовности навигации
[ ] перейти к определению функции из другого пакета
[ ] найти все использования метода и пройтись по списку
[ ] переименовать символ во всём проекте и проверить, что тесты зелёные
[ ] поставить точку останова, запустить отладчик, посмотреть значение переменной
[ ] запустить один тест из редактора и увидеть результат
[ ] сделать коммит, разрешить конфликт слияния
[ ] открыть лог на 200 МБ и найти в нём строку
[ ] подключиться к удалённой машине и отредактировать конфиг
[ ] вернуться к файлу, который правил вчера, на нужной строке
EOF

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

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

Сравнивать инструмент из коробки с чужим вылизанным конфигом. Neovim после шестидесяти часов настройки против VS Code, поставленного пять минут назад, — это сравнение вложений, а не редакторов.

Выбирать по восторженным обзорам. Обзор пишет человек в фазе «Адаптация» из диаграммы жизненного цикла — то есть на пике новизны. Ценнее отзыв того, кто сидит на инструменте третий год и уже видел все его дефекты.

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

Считать переход бесплатным, потому что инструмент бесплатный. Лицензия — это меньшая часть стоимости. Основная — часы, и они не в прайс-листе.

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

Стандартизировать редактор вместо артефактов. Требование «все пишут в X» вызывает сопротивление и не решает проблему; требование «код отформатирован, тесты запускаются одной командой» решает и сопротивления не вызывает.

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

Забывать про стоимость выхода. Прежде чем вкладываться в инструмент, спросите: что я потеряю, если через два года придётся уйти? Навык работы с модальным редактированием переносится в любой редактор; знание конкретного набора расширений JetBrains — почти нет.

Как это выглядит в реальных командах

Несколько устойчивых конфигураций, которые встречаются в продакшене чаще других — и почему они устойчивы.

Java-команда в банке. IntelliJ IDEA Ultimate у всех, потому что альтернатива по рефакторингам проигрывает слишком заметно, а стоимость лицензии на фоне зарплат несущественна. Vim-навык при этом требуется всем, потому что прод — это SSH на машину, где ничего, кроме vi, нет.

Продуктовая команда на TypeScript и Go. VS Code как путь по умолчанию, два-три человека на Neovim, все на одном devcontainer. Работает, потому что стандартизированы контейнер, форматтер и команда запуска тестов, а не редактор.

Инфраструктурная команда. Neovim или Helix почти у всех, tmux, много SSH. Тяжёлые IDE не приживаются: работа идёт на десятке машин, редактор должен быть там, где данные.

Смешанная команда с монорепозиторием. Гибрид как норма: IDE открывается ради крупного рефакторинга и отладки, лёгкий редактор — для повседневных правок. Это не признак нерешительности, а рациональный ответ на то, что у инструментов разные формы.

Общее у всех четырёх: вопрос «какой редактор лучше» в них никогда не решался голосованием. Он решался тем, какие ограничения у работы — язык, размер, способ доступа к машинам, состав команды.

Мини-итог

• Сравнивать надо связки «инструмент плюс язык плюс размер проекта плюс способ работы», а не инструменты. Утверждение без единицы измерения бессодержательно.
• Критерии делятся на возможности, издержки и риски. Обсуждают обычно первое, платят за второе, страдают от третьего.
• Измеримое измеряйте сами и на своём проекте: старт, отклик, задержку автодополнения, память, поведение на большом файле. Чужие бенчмарки — на чужих репозиториях.
• Считайте взвешенно, но веса записывайте до подсчёта. Колонка «слабое место» полезнее итогового балла: вас убьёт провал по важной оси, а не среднее.
• После LSP и DAP разрыв в возможностях сократился почти везде. Незакрытыми остались надёжные рефакторинги и отладка из коробки — это и есть то, за что платят JetBrains.
• Стоимость владения самосборным конфигом — порядка шестидесяти дополнительных часов за два года. Это цена, а не приговор, но её надо вносить в смету.
• В команде стандартизируйте артефакты: EditorConfig, форматтер, проверку в CI, devcontainer. Редактор оставьте личным делом — так меньше сопротивления и больше порядка.
• Меняйте инструмент экспериментом с заранее записанным критерием успеха и никогда — во время дедлайна.

Источники

• Language Server Protocol Specification и Debug Adapter Protocol — два документа, объясняющие, почему сравнения до 2016 года устарели.
• Павел Фатин, Typing with Pleasure — измерение задержки ввода в редакторах, методика и инструмент Typometer.
• hyperfine — бенчмарк командной строки, которым удобно мерить холодный старт.
• EditorConfig — переносимая договорённость о форматировании.
• Development Containers Specification — воспроизводимое окружение независимо от редактора.
• Stuart Card, Thomas Moran, Allen Newell, The Psychology of Human-Computer Interaction — первоисточник по GOMS и стоимости переучивания моторных навыков.
• Tom DeMarco, Timothy Lister, Peopleware — о том, почему разброс между людьми больше разброса между инструментами.
• the-homeless-god/Dotfiles — публичная конфигурация, которую мы разбирали в статьях про Neovim и терминальный workflow.
• Прайс JetBrains и лицензирование Visual Studio — сверяйте цифры на момент решения, они меняются.

Что дальше

Это последняя статья трека «Редакторы и IDE». Инструмент выбран, настроен и, надеемся, перестал быть предметом спора — теперь он должен приносить пользу в чём-то содержательном.

Если хочется двигаться дальше по портфелю навыков, вот разумные направления:

• Терминальный рабочий процесс — если вы пропустили предыдущую статью, она про то, что окружает редактор: tmux, оболочку и синхронизацию dotfiles между машинами.
• DevOps — правая часть петли обратной связи: CI, сборки, доставка. Там выигрыши обычно больше, чем в редакторе.
• Операционные системы — процессы, память и файловые системы, без понимания которых трудно объяснить, почему ваша IDE съела всю RAM.
• Базы данных и принципы разработки — содержательные области, ради которых инструмент, собственно, и настраивался.
• Управление проектами — если вы дошли до стадии, когда решения об инструментах принимаются не только за себя.

А общая карта портала с порядком прохождения треков — здесь: Дорожная карта.