code-review-and-quality

Code Review and Quality — это навык многоосевого ревью, который следует применять перед слиянием изменения, после реализации функции, рефакторинга или исправления ошибки. Его задача — не просто найти стилистические замечания, а последовательно проверить, улучшает ли изменение общее состояние кодовой базы. В исходном SKILL.md заданы пять осей: корректность, читаемость, архитектура, безопасность и производительность. На оси корректности проверяются соответствие задаче, граничные случаи, null и пустые значения, обработка ошибок, тесты, off-by-one, гонки и согласованность состояния. Это помогает отличить проверку поведения от субъективного спора о стиле. Читаемость рассматривает имена, прямолинейность управления, вложенные callbacks и ternary-выражения, мёртвый код, лишние обёртки и абстракции, которые нельзя объяснить третьим вариантом использования. Архитектурная часть проверяет границы модулей, направление зависимостей, дублирование, утечки feature-specific логики в общие компоненты и неясные типовые границы. Для структурных проблем источник предлагает не ограничиваться фразой «сложно»: заменить цепочку условий явным dispatcher или моделью, схлопнуть повторные ветки, отделить orchestration от business logic, вернуть feature-specific код владельцу или удалить pass-through wrapper. В security-части рассматриваются валидация пользовательского ввода, аутентификация и авторизация, параметры SQL, XSS, секреты и обращение с внешними данными как с недоверенными. Это полезный минимум для ревью, но сам источник направляет за детальной методикой в отдельный security-and-hardening skill, поэтому карточка не обещает полноценный security-аудит. На оси производительности проверяются N+1, неограниченные выборки, синхронная работа в неподходящем месте, лишние перерендеры и отсутствие пагинации. Навык также задаёт критерий одобрения: изменение можно принять, когда оно определённо улучшает здоровье проекта, даже если не идеально и написано не так, как написал бы ревьюер. Такой критерий снижает риск блокировать полезную работу из-за вкусовых различий, сохраняя внимание к фактическому регрессу. Практический сценарий — пройти пять осей по небольшому diff до merge, затем сформулировать не только проблему, но и конкретное структурное решение. Размер изменения тоже входит в качество: источник считает около ста строк хорошим объёмом для одного логического изменения, около трёхсот допустимым при единой цели, а около тысячи — сигналом к разделению. Навык не заменяет запуск тестов, линтера, type-check, профильных security-инструментов или нагрузочного измерения: он помогает проверить, что такие проверки уместны и что их результат действительно подтверждает изменение. Его ограничение — ревьюер должен понимать контекст продукта и контрактов; без него даже пять формальных осей не докажут корректность решения. Перед слиянием полезно зафиксировать проверяемые вопросы и отделить обязательные дефекты от предпочтений реализации.