Инженерная практика
Code review: тест на свободное припоминание
Припоминание бьёт перечитывание. Для каждого промпта произнеси или запиши полный ответ по памяти, прежде чем открыть модельный — усилие вытащить его и закрепляет операционную модель юнита.
Реконструируй хребет юнита — назначение ревью, рычаг PR size, историю latency, действенный фидбэк с пометкой важности, author preparation и то, как ревью масштабируется — не подглядывая в уроки.
- 01Какова реальная граница между тем, что должен ловить человек-ревьюер, и тем, что тулинг, и почему это не «важность»?
- 02Почему PR в 1600 строк получает МЕНЬШЕ эффективного ревью, чем в 160, и какие данные это поддерживают?
- 03Почему «ревьюить быстрее» обычно неверная инструкция для latency и какую переменную менять вместо этого?
- 04Какие две вещи каждый комментарий ревью обязан сделать явными, как их кодировать и чего стоит непомеченный nitpicking?
- 05Что SmartBear нашёл об author preparation и почему психологическая безопасность важна для ревью?
- 06Как масштабировать code review в растущей организации и когда менять форму ревью, а не просто ускорять его?
Если ты смог реконструировать каждый ответ по памяти, ты держишь хребет юнита: ревью существует для неразрешимого, поэтому автоматизируй разрешимое в блокирующий гейт; PR size — главная переменная, задающая latency и обнаружение вместе, и маленькие или stacked PR двигают обе; latency доминируется подхватом, поэтому сокращай время обслуживания, а не дави на часы; фидбэк работает, когда называет важность и фикс и целится в код; собственная аннотация автора ловит дефекты, которых не видит ни один ревьюер; а на масштабе ты маршрутизируешь на команду, ограничиваешь подхват, не завершение, балансируешь нагрузку и меняешь форму — pairing или post-commit на протестированной базе — меряя исходы, никогда активность.