code-review-excellence

Навык Code Review Excellence превращает проверку изменений из gatekeeping-процесса в последовательный обмен знаниями. Он предназначен для ревью pull request, подготовки стандартов команды, наставничества, архитектурной проверки, составления checklist и сокращения цикла ревью. Целью считаются поиск дефектов и крайних случаев, поддерживаемость, обмен контекстом, согласование стандартов, проверка дизайна и командное взаимодействие. Показать экспертность, придраться к форматированию или заблокировать изменение из-за личного предпочтения источником не считаются целями code review. Хороший комментарий должен быть конкретным, применимым, образовательным и направленным на код, а не на человека. Источник рекомендует балансировать замечания, отмечать удачные решения и явно отделять критичное от необязательного. Вместо расплывчатого «это неправильно» стоит описать наблюдаемое последствие и возможный путь проверки; вместо приказа использовать вопрос или предложение, если решение зависит от контекста. Такой стиль не отменяет обязательного исправления security или correctness-проблемы, но делает причину и приоритет понятными для автора. Workflow начинается с контекста: прочитать описание PR и связанную задачу, оценить размер изменения, проверить CI и понять бизнес-требование вместе с архитектурными решениями. На высоком уровне затем проверяются соответствие решения проблеме, наличие более простого подхода, согласованность с существующими паттернами, перспективы масштабирования, расположение файлов и стратегия тестирования. Только после этого выполняется построчный проход. Такой порядок снижает риск обсуждать отдельную строку, не понимая, зачем вообще был выбран данный дизайн. Построчная проверка охватывает логику и edge cases, off-by-one, null/undefined, race conditions, безопасность входных данных, SQL injection, XSS, утечки секретов, N+1 queries, индексы, пагинацию, memory leaks, блокирующий I/O, имена и размер функций. Форматирование, импорт и простые опечатки предлагается отдавать автоматическим инструментам вроде линтера или formatter-а. Для повторяемости источник рекомендует отдельные checklist: security с validation, parameterized queries, auth и secrets; performance с N+1, индексами, большими списками и cache; testing с happy path, edge cases, ошибками, читаемостью и детерминизмом. В финале ревьюер кратко суммирует главные риски, отмечает сильные стороны и принимает понятное решение: approve, комментарий для мелких предложений или request changes для обязательных исправлений. Для комментариев используются уровни вроде blocking, important, nit, suggestion, learning и praise. Их смысл — сообщить срочность и действие, а не выставить автору субъективную оценку. Вопросный подход полезен для ситуаций «что произойдёт при пустом списке?» или «как поведёт себя API при ошибке?», когда нужно открыть проверяемый сценарий, а не навязать конкретный паттерн. Навык не заменяет CI, тесты, security tooling, профилирование или знание доменной модели. Checklist не доказывает отсутствие уязвимостей, а формальная рекомендация по размеру PR не является универсальным лимитом для каждой команды. Результат нужно сверять с фактическим кодом, требованиями, архитектурой и поведением в тестах; комментарий «проверьте race condition» не равен воспроизведённой ошибке. Его ценность — в коротком, повторяемом порядке чтения изменений и в качестве обратной связи, а не в автоматическом verdict без человеческого контекста.