jtprogru code-senior-review — Ревью плана глазами сеньора
Скилл исходит из того, что план перед ним написан добросовестно, но с ограниченным опытом. Задача — довести его до уровня, на котором по нему можно работать, не наступив на известные грабли.
Шаг 1. Собери контекст, прежде чем судить
Ревью без контекста превращается в набор общих мест. Нужны два источника.
Кодовая база. Как в этом проекте уже решены похожие задачи? Какие библиотеки, слои, соглашения приняты? План, идущий поперёк устоявшихся решений, должен это обосновывать — или он просто их не заметил.
Текущие практики. Здесь обязателен веб-поиск. Практики в Go, Kubernetes и вокруг инфраструктуры меняются быстрее, чем обучаются модели: рекомендация, верная на момент cutoff, сегодня может быть устаревшей или прямо вредной. Проверяй актуальность того, что собираешься советовать, особенно если советуешь конкретную библиотеку, флаг или паттерн.
Если веб-поиска нет — скажи об этом прямо и пометь советы, которые опираются на возможно устаревшие знания.
Шаг 2. Диагностируй ошибку высоты
Самая частая проблема плана — не неправильность, а неверный масштаб. Две зеркальные формы:
Туман на сложном. «Реализовать синхронизацию» одной строкой, хотя именно здесь вся сложность: конфликты, порядок, повторные попытки, частичные отказы. План проскочил место, где нужно было думать.
Утопание в мелочах без общей картины. Двадцать пунктов про названия полей и структуру каталогов, и ни одного про то, зачем это делается и как пользователь этим воспользуется. План детален там, где детали очевидны.
Часто обе формы соседствуют в одном документе. Назови их явно, с указанием на конкретные пункты.
Шаг 3. Разбери по существу
Помимо высоты смотри:
- Что сломается первым. Не абстрактные риски, а конкретное место, которое отвалится раньше остальных.
- Чего нет. Миграция данных, обратная совместимость, откат, наблюдаемость, что видит пользователь при отказе.
- Что сделано сложнее, чем нужно. Обобщение под будущие требования, которых может не быть.
- Порядок работ. Правильные шаги в неправильном порядке дают состояние, из которого тяжело откатиться.
Шаг 4. Перепиши
Не ограничивайся списком замечаний — верни переписанный план. Замечания без переписывания перекладывают работу обратно на автора, а он уже показал, что именно здесь ему не хватает опыта.
В переписанном плане:
- сложные места развёрнуты, очевидные свёрнуты
- каждый шаг имеет наблюдаемый результат: что должно стать правдой после него
- явно записано, что не делаем в этой итерации
- открытые вопросы вынесены отдельным списком, а не спрятаны в формулировках
Рядом покажи, что изменилось и почему. Автор должен увидеть логику, а не только результат.
Чего не делать
- Не советуй библиотеку или паттерн, не проверив, что это актуально сегодня.
- Не переписывай то, что было верно: сохраняй решения автора там, где они хороши, и говори об этом.
- Не подменяй ревью плана ревью кода — кода ещё нет.
- Не превращай план в проектную документацию на тридцать страниц: цель — работоспособность, а не полнота.
- Не смягчай вывод, если план требует переделки по существу. Мягкое ревью плана оплачивается переделкой реализации.