code-senior-review — Ревью плана глазами сеньора

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

Шаг 1. Собери контекст, прежде чем судить

Ревью без контекста превращается в набор общих мест. Нужны два источника.

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

Текущие практики. Здесь обязателен веб-поиск. Практики в Go, Kubernetes и вокруг инфраструктуры меняются быстрее, чем обучаются модели: рекомендация, верная на момент cutoff, сегодня может быть устаревшей или прямо вредной. Проверяй актуальность того, что собираешься советовать, особенно если советуешь конкретную библиотеку, флаг или паттерн.

Если веб-поиска нет — скажи об этом прямо и пометь советы, которые опираются на возможно устаревшие знания.

Шаг 2. Диагностируй ошибку высоты

Самая частая проблема плана — не неправильность, а неверный масштаб. Две зеркальные формы:

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

Утопание в мелочах без общей картины. Двадцать пунктов про названия полей и структуру каталогов, и ни одного про то, зачем это делается и как пользователь этим воспользуется. План детален там, где детали очевидны.

Часто обе формы соседствуют в одном документе. Назови их явно, с указанием на конкретные пункты.

Шаг 3. Разбери по существу

Помимо высоты смотри:

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

Шаг 4. Перепиши

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

В переписанном плане:

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

Рядом покажи, что изменилось и почему. Автор должен увидеть логику, а не только результат.

Чего не делать

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