code-review

Скилл code-review от Sentry предназначен для ревью pull request и других изменений кода по инженерным практикам. Его задача — помочь системно искать риски в изменениях, а не заменить решение ответственного разработчика. В исходном SKILL.md область проверки разделена на качество кода, безопасность, производительность, тестирование и архитектурный дизайн. Такой охват делает карточку полезной как короткий маршрут перед ревью: сначала проверяется, не ломается ли поведение, затем оцениваются последствия для эксплуатации и проекта. В разделе поиска проблем источник предлагает начинать с потенциальных runtime-ошибок: исключений, обращения к null и выхода за границы. Отдельно проверяется производительность, включая неограниченные операции O(n²), N+1-запросы и ненужные аллокации. Ревьюер также должен искать непреднамеренные побочные эффекты, несовместимые изменения без пути миграции, сложные ORM-запросы с неожиданной стоимостью и уязвимости. В список security-проверок прямо входят injection, XSS, пробелы в контроле доступа и случайная публикация секретов. Это не универсальная гарантия безопасности, а набор направлений, которые нужно сопоставить с конкретным diff и доверенной границей системы. Для design assessment скилл предлагает проверить логичность взаимодействия компонентов и соответствие изменения архитектуре, текущим требованиям и целям проекта. На уровне тестов он ожидает подходящее покрытие для функциональной логики, интеграционных взаимодействий и критических пользовательских путей end-to-end. При этом нужно проверять реальные требования и edge cases, а не увеличивать количество тестов механически; источник отдельно предупреждает против чрезмерной ветвистости и циклов в тестовом коде. Долгосрочные риски требуют отдельного внимания старшего инженера, если изменение затрагивает схему базы данных, API-контракт, новый framework или библиотеку, производительно-критичный путь либо security-sensitive функциональность. В качестве практических примеров SKILL.md показывает N+1 в Django ORM и исправление через prefetch_related, отсутствующую зависимость useEffect в TypeScript/React и параметризованный SQL вместо сборки запроса через интерполяцию. Эти примеры иллюстрируют тип проверки, но не отменяют анализа фактического проекта. Формат обратной связи тоже является частью workflow. Скилл рекомендует вежливый и эмпатичный тон, конкретные действия вместо расплывчатой критики и формулировку вопросом там, где есть неопределённость. Незначительные замечания не должны блокировать pull request из-за личных стилевых предпочтений: критерий — снижение риска. Ограничение карточки следует из источника: это чек-лист и правила коммуникации для code review, а не автоматический сканер, формальная сертификация безопасности или решение о merge без проверки человеком.