Рабочее место как у профи: tmux + Neovim в реальном дне

Три предыдущие главы разобрали каждый инструмент по отдельности: систему, редактор, мультиплексор. Но инструменты не работают по отдельности — работаешь ты, и работаешь в связке. Эта глава — про связку: как выглядит реальный день разработчика, у которого Omarchy под ногами, tmux держит рабочие места, а Neovim — единственное место, где правится код.

Материал построен вокруг трёх сценариев, которые ты узнаешь из собственной практики: обычная фича от лида до пул-реквеста, ночной дебаг продакшена по SSH и code review чужой ветки. Для каждого разберём layout, последовательность действий и те места, где стек экономит минуты, которые у остальных уходят в клики. В конце — советы по выработке мышечной памяти и честная карта «когда что использовать», потому что фанатизм в инструментах — признак джуна, а не сеньора.

Если предыдущие главы ты читал «на коленке», эту стоит читать, повторяя всё руками на pet-проекте. Именно здесь SaaS-дашборд из плана учебника встречается с рабочим местом: все сценарии ниже — про него.

Типичный layout: анатомия рабочего места

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

Сессия: dashboard
┌─ Окно 1: code ──────────────────────────────────────────┐
│ ┌────────────────────────────────────┬──────────────────┤
│ │                                    │                  │
│ │   nvim (основная панель, ~70%)     │  dev-сервер или  │
│ │                                    │  логи (справа)   │
│ ├────────────────────────────────────┤                  │
│ │   тесты в watch-режиме (снизу)     │                  │
│ └────────────────────────────────────┴──────────────────┘
└─ Окно 2: git — lazygit на весь экран ───────────────────┘

Логика такова. Окно — это режим работы, панель — это поток данных. Код и всё, что про код, — в окне code: редактор слева (где ты думаешь), тесты снизу (обратная связь после каждого сохранения), dev-сервер справа (состояние приложения). Git — отдельным окном: коммиты и ветки — другой режим мышления, ему положен весь экран, а не уголок панели. Alt+1 и Alt+2 переключают между режимами мгновенно — и это вся «навигация по рабочему месту».

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

Правило одного взгляда

Раскладывай панели так, чтобы ответ на вопрос, который ты задаёшь чаще всего, требовал ноль переключений. «Зелёные ли тесты?» — видно всегда. «Что в логах?» — одна Alt-комбинация. Если для ответа на частый вопрос нужно переключиться — layout устроен неправильно.

Сценарий 1: фича от лида до пул-реквеста

Утро, в трекере задача: «добавить в дашборд фильтр по дате». Смотри, как разворачивается час работы.

09:00 — подъём рабочего места. ./dev.sh (скрипт из главы про tmux) поднимает сессию dashboard: nvim в первом окне, тесты снизу, lazygit во втором. Пока всё стартует — читаешь задачу. Руки с клавиатуры не уходили.

09:02 — навигация по незнакомому месту. Фильтр живёт где-то в таблице данных. Space Space, печатаешь datatable — файл найден, Enter. Внутри файла gd по компоненту фильтра — прыжок к его определению, читаешь, Ctrl+o — назад. LSP-сервер делает за тебя то, для чего в GUI-редакторе нужна мышь и панель «поиск по проекту».

09:10 — код. Пишешь фильтр. blink.cmp подсказывает пропсы по мере ввода, Enter принимает. Нужно обернуть JSX в условный рендер — gsa от mini.surround. Опечатка в имени пропса — красное подчёркивание от LSP, Space ca — «добавить недостающий импорт». Сохранил — панель снизу мигнула: тесты прогнались, зелёное.

09:40 — коммит. Alt+2 — lazygit. Видишь изменённые файлы, staging по хункам: этот хунк в коммит, этот — дебажный console.log, его откатываем, а не коммитим. Conventional commit: feat(dashboard): фильтр по дате в таблице. Alt+1 — назад в код.

09:55 — PR. gh pr create в той же панели, где жил dev-сервер (он уже остановлен — окно code, нижняя панель свободна). Ссылка на PR ушла в чат. Весь сценарий — ноль прикосновений к мыши, ноль переключений между приложениями ОС: всё произошло внутри одной сессии tmux на одном воркспейсе Hyprland.

Из практики: такой сценарий в GUI-среде стоит ~20-30 переключений окон и переносов рук. Каждое переключение — не секунда, а микроразрыв внимания: после «нашёл нужную вкладку» мозг заново собирает контекст. Час глубокой работы в стеке против часа работы с мышью — это не «на пять минут быстрее», это заметно больше сделанного и заметно меньше усталости.

Сценарий 2: дебаг продакшена по SSH

Два часа ночи, алерт: у части пользователей дашборд показывает вчерашние данные. Это сценарий, где терминальный стек перестаёт быть «удобным» и становится единственно возможным.

Подключение и безопасность сессии. ssh prod, первое действие — tmux new -s incident (или tmux attach, если сессия уже есть). Теперь ни обрыв VPN, ни случайно закрытый терминал не прервут расследование на середине: всё, что ты натейлил и нашёл, переживёт переподключение.

Параллельные потоки. Расследование — это несколько потоков данных одновременно. Alt+Enter — сплит: слева journalctl -u dashboard-api -f (живой поток логов сервиса), справа — шелл для команд. Нашёл подозрительную строку — префикс+[, / по тексту ошибки, v/y — скопировать стектрейс; OSC52 донёс его до локального буфера, и он уже вставлен в чат инцидента с десктопа.

Гипотеза и проверка. Подозрение на кэш: вторая панель — redis-cli, смотришь TTL ключей. Гипотеза подтверждается: ключи не инвалидируются. Нужно поправить конфиг прямо на сервере — nvim /etc/dashboard/config.yaml, и здесь весь перенос навыков срабатывает: те же ciw, та же навигация, что и дома. Никакого «как тут nano сохранить».

Фикс и postmortem. Конфиг поправлен, сервис перезапущен, логи в левой панели показывают здоровые запросы. Сессию incident не убиваешь — оставляешь до утра: в ней вся история команд и найденных логов, из которых утром пишешь postmortem (помнишь главу про инцидент-менеджмент). Скроллбэк tmux — твой черновик расследования.

Продакшен — не место для экспериментов с конфигом

Ночной дебаг — плохое время выяснять, что на сервере tmux с дефолтным префиксом и без copy-mode vi. Держи минимальный серверный конфиг (префикс, mode-keys vi, escape-time 0, set-clipboard on) в dotfiles и раскатывай его на серверы заранее — тем же Ansible, что и остальную конфигурацию. Окружение на сервере — тоже IaC.

Сценарий 3: code review

Третий режим — чтение чужого кода. Пришёл PR на дашборд, коллега просит посмотреть сегодня.

Разворачиваем ветку рядом. Не переключая свою рабочую сессию, поднимаешь ревью-контекст: новое окно tmux (prefix c), gh pr checkout 143, nvim .. Твоя работа в первом окне не тронута — это важно: review не должно ломать твой flow, иначе ты начнёшь его откладывать.

Чтение diff как навигация. Space gg — lazygit, в нём diff PR по файлам. Увидел подозрительную функцию — запомнил имя, вернулся в nvim, Space / по имени — все места использования. gd по вызовам, Ctrl+o назад. Чужой код читается «гипертекстом»: прыгнул в определение, посмотрел ссылки (gr), вернулся. Линейное чтение diff сверху вниз — так ревьюят поверхность; гипертекстом ревьюят семантику: «эта функция теперь возвращает null — а кто-то ещё это выдержит?»

Комментарии. Замечания собираются прямо по ходу: "+y скопировал фрагмент, в браузере (Super+2, второй воркспейс) комментарий к строке в PR. Всё. Ревью заняло двадцать минут, и ни разу ты не искал «где это в каком файле» скроллом.

Мышечная память: как её выращивают

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

Первый: одна фраза в день. Не «выучить всё», а одна новая конструкция, которую ты заставляешь себя использовать весь день. Сегодня — ciw, завтра — Alt+сплиты, послезавтра — Ctrl+o после каждого gd. Две недели — и у тебя пятнадцать новых рефлексов, причём зафиксированных практикой, а не зубрёжкой.

Второй: штраф за мышь. Каждый раз, когда рука тянется к мыши, — стоп, отмени действие, сделай клавиатурой, пусть медленно. Звучит мучительно — и является мучительным ровно три дня. Дальше рука перестаёт тянуться. Можно упростить себе жизнь радикально: отключить мышь в tmux и убрать её подальше на время тренировки.

Третий: единый словарь. Сила стека — в том, что концепции повторяются на всех уровнях: воркспейсы Hyprland ≈ окна tmux ≈ буферы Neovim; Super+цифры, Alt+цифры, Shift+h/l — одна идея «прыжка по номеру/порядку» на трёх этажах. Когда словарь един, каждый новый уровень учится за счёт предыдущего. Поэтому не смешивай подходы: если выбрал vi-клавиши — пусть они будут везде, где доступны (copy-mode tmux, lazygit, less).

Плато — это норма

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

Карта «когда что использовать»

Честная таблица, без религии:

Задача	Инструмент	Почему
Правка кода, рефакторинг, навигация по проекту	Neovim + LSP	семантическая навигация и язык редактирования
Долгие процессы, SSH, параллельные потоки	tmux	выживаемость сессий и панели
Коммиты, staging по хункам, rebase	lazygit	интерактивность там, где CLI git многословен
Отладка с точками останова, сложный профайлинг	IDE (VS Code / JetBrains)	отладчики и визуальные профилировщики там сильнее
Быстрый просмотр больших diff	lazygit или GitHub web	визуальный diff читается быстрее
Дизайн, макеты, DevTools браузера	GUI	терминал тут не конкурент
Разовая команда на сервере	просто ssh + команда	tmux не нужен для systemctl status

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

Типичные ошибки и грабли

• Переделывать конфиг каждую неделю. Новый плагин, новая раскладка хоткеев — и мышечная память обнуляется. Хорошо: «заморозка» конфига на месяц, изменения — списком, применяются разом.
• Сессия «на всё» и окна «вкладка 1..20». Возврат хаоса вкладок внутри tmux. Сессия на проект, окна по режимам работы, лишние убиваются вечером.
• Учить стек на рабочем дедлайне. Первую неделю ты медленнее — не планируй переход на неделю релиза. План из главы про Neovim рассчитан на спокойный период.
• Панели-музей. Пять панелей, из которых три — «когда-то пригодится». Панель стоит внимания: не смотрел в неё час — убей, откроешь за секунду, когда понадобится.
• Копипаст чужого dotfiles целиком. Чужой конфиг — это чужие привычки и чужие костыли. Бери идеи, пиши строки сам.
• Забыть про серверный конфиг. Локальный стек доведён до блеска, а на проде дефолт — и ночной инцидент встречает тебя Ctrl+b и отсутствием copy-mode. Серверный минимум раскатывается заранее.

Вопросы на собеседовании

1. Опиши своё рабочее окружение и почему оно такое. Правильный ответ — не перечисление софта, а принципы: клавиатурная навигация без переноса рук, воспроизводимость через dotfiles, единый словарь клавиш на всех уровнях, выживаемость сессий на удалённых машинах. Софт — следствие принципов.
2. Как ты организуешь работу над несколькими проектами? Сессия tmux на проект с фиксированным layout (код + тесты + git-окно), скрипт подъёма рабочего места, воркспейсы Hyprland по типам активности. Переключение контекста — одна комбинация клавиш, восстановление контекста — один скрипт.
3. Ты быстрее в терминале — это про скорость печати? Нет: про устранение переключений контекста. Перенос руки на мышь и поиск окна глазами — это микроразрыв внимания, а не «секунда». Профит стека — в сохранении потока, скорость нажатий вторична.
4. Как восстановишь окружение на новой машине? Установка системы → клон dotfiles → симлинки конфигов → установка пакетов по списку → dev.sh поднимает рабочие места. Цель — десятки минут, измеряется практикой: раз в полгода стоит реально проделать это на чистой VM.
5. Когда терминальный стек проигрывает GUI? Визуальная отладка с точками останова, профайлеры, работа с дизайном и браузерными DevTools, разовые действия. Сеньор выбирает инструмент под задачу, а не носит один молоток.
6. Как ты дебажишь инцидент на проде по SSH? Первым делом tmux-сессия (защита от обрыва), панели под логи и команды, copy-mode для сбора улик, OSC52 для переноса фрагментов локально, сессия сохраняется как черновик postmortem.

Практика

1. Напиши свой dev.sh под pet-проект: код + тесты + git-окно, подъём одной командой. Критерий: неделю спустя возвращаешься к проекту и рабочее место восстанавливается за секунды, без «а что у меня там было открыто».
2. Проведи сценарий «фича до PR» целиком в стеке. Небольшая фича дашборда: вся навигация через picker/gd, staging через lazygit по хункам, PR через gh. Засеки время и число прикосновений к мыши (цель — ноль).
3. Устрой учебный инцидент. Подними pet-проект на VPS, «сломай» его (неверный конфиг, упавший сервис) и дебажь по SSH строго по сценарию из главы: tmux-сессия, панели, copy-mode, фикс через nvim на сервере.
4. Сделай одно ревью гипертекстом. Чужой PR (в опенсорс-проекте, если нет коллег): чтение через lazygit → Space / → gd → gr → Ctrl+o. Выпиши два семантических замечания, которые diff-скроллинг бы не дал.
5. Заморозь конфиг на месяц. Закоммить dotfiles, поставь себе напоминание через 30 дней. Всё, что хочется поменять, — в список «потом». Критерий: через месяц конфиг тот же, а скорость выросла — значит, работала память, а не тюнинг.

Что почитать

• LazyVim: Keymaps — полная карта хоткеев дистрибутива, твоя шпаргалка на первый месяц.
• tmux: Productive Mouse-Free Development — книга про tmux как среду ежедневной работы, а не набор команд.
• Omarchy Manual — официальное руководство по системе: хоткеи, команды, философия.
• GitHub CLI — gh pr create, gh pr checkout и весь CLI-слой GitHub, который связывает стек с платформой.
• lazygit — репозиторий с документацией и демо: staging по хункам, интерактивный rebase.