Установка скиллов и плагинов OpenClaw осуществляется на ваш страх и риск. Все файлы были получены из открытых источников и предоставляются «как есть». Мы не гарантируем их корректную работу, безопасность или совместимость с вашей системой. Перед установкой настоятельно рекомендуется ознакомиться с содержимым кода и убедиться, что вы понимаете, какие изменения будут внесены в вашу систему.
Системный подход к код-ревью — это не просто поиск ошибок, а полноценная проверка качества разработки по нескольким ключевым направлениям: безопасность, производительность, корректность, поддерживаемость и тестирование. Ниже представлен структурированный чек-лист, который помогает проводить ревью последовательно и эффективно.
Что входит в чек-лист
- Ключевые направления ревью с приоритетами (Безопасность → Производительность → Корректность → Поддерживаемость → Тестирование → Доступность → Документация)
- Проверка безопасности (SQL-инъекции, XSS, CSRF, авторизация, секреты, rate limiting)
- Проверка производительности (N+1 запросы, лишние рендеры, утечки памяти, размер бандла, кеширование)
- Проверка корректности (граничные случаи, обработка null, гонки, работа с часовыми поясами)
- Проверка поддерживаемости (именование, SRP, DRY, мёртвый код, направление зависимостей)
- Проверка тестирования (покрытие, edge-case’ы, нестабильные тесты, корректность моков)
- Трёхэтапный процесс ревью (общий обзор → построчный анализ → проверка крайних случаев)
- Уровни критичности (Critical, Major, Minor, Nitpick) с рекомендациями по блокировке мержа
- Принципы обратной связи и примеры комментариев
- Антипаттерны код-ревью, которых следует избегать
Приоритеты при ревью
Ревью следует проводить в строгом порядке приоритетов. Сначала проверяется безопасность — любые уязвимости критичны. Затем оценивается производительность, после чего — корректность логики. Только после этого имеет смысл переходить к вопросам читаемости, архитектуры и тестирования.
Проверка безопасности
Обратите внимание на типичные уязвимости: SQL-инъекции, XSS, CSRF. Проверьте, как реализована авторизация, не утекли ли секреты, и есть ли ограничения на частоту запросов. Любая проблема в этой области должна рассматриваться как приоритетная.
Производительность
Ищите неэффективные паттерны: N+1 запросы, лишние перерендеры, утечки памяти. Оцените размер бандла и использование кеширования. Даже небольшие проблемы могут масштабироваться в серьёзные узкие места.
Корректность
Проверьте обработку крайних случаев, null-значений, гонок и особенностей времени (таймзоны). Ошибки в логике часто менее заметны, но могут приводить к критическим сбоям.
Поддерживаемость
Оцените читаемость кода: понятны ли имена, соблюдаются ли принципы SRP и DRY, отсутствует ли мёртвый код. Важно также следить за направлением зависимостей и общей структурой проекта.
Тестирование
Проверьте наличие тестов, их покрытие и устойчивость. Обратите внимание на обработку крайних случаев и корректность использования моков. Нестабильные тесты могут быть так же вредны, как и их отсутствие.
Процесс ревью: три этапа
- Общий обзор: понимание цели изменений и их влияния на систему
- Построчный анализ: детальная проверка каждой части кода
- Крайние случаи: поиск нестандартных сценариев и потенциальных ошибок
Уровни критичности
- Critical: блокирует merge, требует немедленного исправления
- Major: серьёзная проблема, должна быть исправлена до релиза
- Minor: улучшение, не блокирует merge
- Nitpick: косметические замечания
Принципы обратной связи
Комментарии должны быть конструктивными, конкретными и направленными на улучшение кода. Важно объяснять «почему», а не только «что не так», и предлагать возможные решения.
Антипаттерны ревью
Избегайте поверхностных проверок, излишней субъективности и фокуса на несущественных деталях. Ревью должно приносить реальную ценность, а не превращаться в формальность.
Когда использовать
- При проверке pull request или merge request
- Для стандартизации процессов ревью в команде
- Для повышения качества и консистентности кода
- Для обучения новых разработчиков
Файл из источника