Как происходит кодревью

Что проверяют

Как вы относитесь к ревью: как к формальности перед мержем или как к инструменту качества и обмена знаниями. Следом спрашивают, что вы смотрите в чужом коде в первую очередь и как ведёте себя, когда с замечанием не согласны.

Как отвечать

Опишите процесс так, как он был устроен у вас, с конкретикой по стеку:

• до ревью: автор делает небольшой PR, пишет описание со ссылкой на задачу и сам просматривает дифф. CI в это время собирает проект (dotnet build, dotnet test), проверяет стиль через .editorconfig и dotnet format --verify-no-changes, гоняет анализаторы Roslyn и, если есть, SonarQube. Всё, что ловит машина, человеку проверять не нужно;
• правила ветки: в Azure DevOps, GitHub или GitLab условием мержа ставят обязательных ревьюеров, зелёный CI и закрытые обсуждения;
• что смотрит ревьюер: корректность логики и граничные случаи, затем специфичное для .NET. Блокирующие .Result и .Wait() в асинхронном коде, async void вне обработчиков событий, потерянный CancellationToken, незакрытые IDisposable, N+1 и лишнее отслеживание в EF Core, scoped-зависимость внутри singleton;
• формат замечаний: отделять блокирующие от необязательных («nit»), предлагать вариант, а не только указывать на проблему;
• сроки: договорённость отвечать на ревью в пределах рабочего дня, иначе PR копятся и конфликтуют между собой.

Приведите пример из опыта: какой баг поймали на ревью, какое правило после этого добавили в анализатор или гайдлайн. Если в команде ревью не было, скажите об этом прямо и объясните, как бы его ввели.

Где спотыкаются

Рассказывают только про стиль и именование. Это задача форматтера, а от ревьюера ждут вопросов про логику, конкурентность и работу с ресурсами.

Считают нормой PR на пару тысяч строк. Такой дифф невозможно внимательно прочитать, его пролистывают и одобряют.

На вопрос о несогласии отвечают «делаю, как сказал старший». Лучше описать аргументацию и способ разрешить спор: данные, бенчмарк, решение техлида или правило в гайдлайне.