Инженерная практика
Code review: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту code review — что ловит человек, а что тулинг; PR size и review latency; фидбэк с пометкой важности; масштабирование очереди и анти-паттерны.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает решение, которое ты принимаешь как reviewer или тимлид под реальным давлением — не определение для заучивания, а компромисс, который надо взвесить, когда PR блокирует кого-то и тикают часы.
Цель
Убедись, что связываешь, для чего нужно ревью, почему PR size задаёт и задержку, и обнаружение, как делать фидбэк действенным и как очередь и анти-паттерны меняют ревью на масштабе — тот синтез, к которому вели пять уроков.
Викторина
Completed
Команда хочет, чтобы ревьюеры были тщательнее, и просит всех дополнительно отмечать форматирование, порядок импортов и регистр имён в каждом PR. Почему это неверный ход?
Heads-up Пропуск по договорённости хрупок — уставший ревьюер всё равно напишет nit, а стиль всё равно попадёт в дифф. Фикс структурный: сделать разрешимый класс физически недостижимым для ревью, блокируя на formatter/linter в CI, а не полагаясь на дисциплину.
Heads-up Скорость — не критерий. Часть человеческих суждений медленна, но незаменима. Граница — может ли правило быть оценено механически со стабильным ответом; именно это идёт в гейт, независимо от того, как быстро справился бы человек.
Heads-up Число комментариев — не метрика ни в одну сторону. Диффу может требоваться много содержательных комментариев по дизайну. Суть в том, что человек не должен писать комментарий, который мог бы написать машина — а не в том, что комментарии плохи.
Викторина
Completed
Медианное время подхвата PR ползёт к суткам, а post-merge дефекты растут по мере роста диффов. Какой единственный фикс с наибольшим рычагом?
Heads-up SLA на завершение давит на видимую метрику, вредя реальной: он не создаст свободный 90-минутный блок под дифф в 1500 строк, поэтому ревьюер торопится и скользит, меняя выигрыш по задержке на потерю в обнаружении. SLA помогает на первом отклике, не на качестве.
Heads-up Два ревьюера на дифф в 1600 строк всё равно видят каждый по 1600 строк за пределами чьего-либо когнитивного бюджета — два скольжения вместо одного плюс двойное ожидание подхвата. Число ревьюеров не меняет лимит внимания на человека; меняет его размер диффа.
Heads-up Саммари может помочь, но человеку всё равно надо осмыслить 1600 строк дизайна, чтобы поймать реальный изъян, и дифф всё равно стоит в очереди часами, ожидая блока. Это лечит симптом; причина — batch size.
Викторина
Completed
По данным Google, почему маленькие изменения подхватываются менее чем за час, а очень большие ждут около пяти часов?
Heads-up Это не правило приоритета — это физика очереди. Время обслуживания большого CL превышает свободные зазоры в днях людей, поэтому он ждёт дефицитный блок, а не потому что кто-то его понизил.
Heads-up Это структурное ограничение, а не мотивация. Даже добросовестный ревьюер не прочтёт 1500 строк за пятиминутное окно, поэтому большой CL физически нельзя обслужить, пока не откроется длинный блок.
Heads-up Маленькие CL ревьюят — часто тщательнее. Просто в них дёшево переключиться, поэтому их быстро подхватывают, а не пропускают.
Викторина
Completed
Ревьюер пишет 'consider extracting this' на функции, и автор не может понять, блокирует ли это merge. Что комментарий не делает явным и как это починить?
Heads-up Цель — меньше неоднозначности на комментарий, а не больше комментариев. Лейбл и конкретное действие дают автору сделать всё за один проход; нагромождение туманных комментариев лишь углубляет гадание.
Heads-up Иногда предложенная правка помогает, но ревьюер не всегда знает замысел, а молчаливое переписывание обходит обмен знаниями, ради которого ревью и существует. Устойчивый фикс — помеченный, действенный комментарий, а не захват диффа автора.
Heads-up Лейблы задают важность, а не рассуждение. Действенному комментарию всё ещё нужно «почему», когда оно неочевидно — лейбл дополняет объяснение, а не заменяет его.
Викторина
Completed
Исследование SmartBear/Cisco нашло один фактор на стороне автора с драматическим эффектом на плотность дефектов. Какой это фактор и почему он работает?
Heads-up Выдающийся результат был на стороне автора, не в числе ревьюеров. Лишние ревьюеры каждый всё равно видят тот же дифф под тем же когнитивным лимитом; именно акт объяснения автором сдвигает обнаружение дефектов вверх по потоку.
Heads-up Длина комментариев не была рычагом. Драматический эффект дало аннотирование автором собственного диффа — ego effect и вынужденная перепроверка — а не то, что ревьюеры писали больше.
Heads-up Темп важен (выше ~450 LOC/час обнаружение падает), но самым недооценённым результатом исследования было author preparation, загоняющее плотность к нулю — привычка автора, а не правило темпа ревьюера.
Викторина
Completed
Организация выросла до 200 инженеров; один staff-инженер — единственный CODEOWNER платежей с ~40 ревью/день, и качество сползает в rubber stamp. Какой фикс с наибольшим рычагом?
Heads-up SLA на завершение давит на одного перегруженного человека идти быстрее, что на глубокой очереди означает скользить и штамповать — ровно тот сбой, который чинишь. SLA помогает на первом отклике/подхвате, не на качестве, и не создаст внимания, которого у бутылочного горла нет.
Heads-up Post-commit убирает задержку подхвата, но безопасен лишь на базе высокого доверия с сильным автоматическим фундаментом — а платежи money/security-чувствительны, ровно там post-commit — неверный дефолт. Ты бы поменял бутылочное горло на непроверенные изменения денежного пути в trunk.
Heads-up Число комментариев — ловушка Goodhart: сделай его целью, и ревьюеры начнут производить nitpicks ради числа, разгоняя bikeshedding, пока дизайн всё равно проскакивает — и это ничего не делает с бутылочным горлом из одного человека.
Итог
Сквозная линия юнита — одна операционная модель: ревью существует для неразрешимого — дизайн, замысел, корректность, обмен знаниями — поэтому всякую разрешимую проверку толкай в блокирующий гейт до ревью. PR size — главная переменная, потому что задаёт и задержку (подхват — это очередь по размеру), и обнаружение (внимание — фиксированный бюджет) разом и в одном направлении; маленькие и stacked PR двигают обе. Фидбэк работает, когда называет важность и фикс, а собственная аннотация автора ловит дефекты, которых не видит ни один ревьюер. На масштабе ты маршрутизируешь владение на команду, ограничиваешь подхват (не завершение), балансируешь нагрузку и иногда меняешь форму — pairing или post-commit на протестированной базе высокого доверия. Каждый анти-паттерн — та же инверсия: ревью перестаёт быть про дизайн.