Code review в JavaScript: что проверять и как давать обратную связь
Code review (ревью кода) — это процесс проверки кода одним или несколькими разработчиками перед его слиянием в основную ветку проекта. Для начинающих JavaScript-разработчиков (особенно работающих с Node.js) это не просто формальность, а мощный инструмент обучения и повышения качества. В этой статье мы разберем, на что обращать внимание при ревью и как формулировать замечания, чтобы не обидеть коллегу, а помочь ему расти.
Почему code review важен для JavaScript-проектов?
JavaScript — динамический язык, и ошибки часто проявляются только в рантайме. Code review помогает выявить:
- Логические ошибки и баги;
- Нарушение архитектуры и стиля кода;
- Проблемы с производительностью;
- Уязвимости безопасности (особенно в Node.js).
Кроме того, это отличный способ обмена знаниями в команде. Даже если вы новичок, ваше свежее зрение может заметить то, что пропустил опытный разработчик.
Что проверять в JavaScript-коде: чек-лист
Чтобы ревью было системным, используйте следующий чек-лист. Он разделен на три блока: корректность, читаемость и производительность/безопасность.
1. Корректность и логика
Сначала убедитесь, что код решает поставленную задачу. Проверьте:
- Краевые случаи: Что произойдет, если массив пуст? Если аргумент —
nullилиundefined? - Асинхронность: Правильно ли обработаны промисы? Нет ли «адской» вложенности
.then()? - Типы данных: Используется ли строгая проверка (
===вместо==)?
// Плохо: неявное приведение типов
if (userInput == 0) { ... }
// Хорошо: строгое сравнение
if (userInput === 0) { ... }
2. Читаемость и стиль кода
Код пишется для людей, а не для машин. Проверьте:
- Именование: Переменные и функции должны говорить сами за себя.
getData()лучше, чемfunc1(). - Размер функций: Функция должна делать только одно. Если она длиннее 20-30 строк — возможно, ее стоит разбить.
- Магические числа: Выносите числа и строки в константы.
// Плохо: магическое число
if (status === 404) { ... }
// Хорошо: именованная константа
const HTTP_NOT_FOUND = 404;
if (status === HTTP_NOT_FOUND) { ... }
3. Производительность и безопасность (Node.js)
Для серверного JavaScript это критично:
- Избегайте блокировки Event Loop: Тяжелые синхронные операции (например,
JSON.parseбольших данных) лучше выполнять асинхронно или воркерами. - Обработка ошибок: Всегда используйте
try/catchв асинхронных функциях или.catch()для промисов. - Инъекции: Никогда не конкатенируйте пользовательский ввод напрямую в SQL или shell-команды. Используйте параметризованные запросы.
// Плохо: уязвимость к SQL-инъекции
const query = `SELECT * FROM users WHERE id = ${userId}`;
// Хорошо: параметризованный запрос
const query = 'SELECT * FROM users WHERE id = $1';
Как давать обратную связь: 5 золотых правил
Даже самый правильный чек-лист бесполезен, если обратная связь вызывает у автора кода желание уволиться. Вот как сделать ревью конструктивным:
Правило 1: Начинайте с позитива
Найдите хотя бы одну вещь, которая сделана хорошо. «Отличное решение с кэшированием!» — это поднимает настрой и показывает, что вы смотрите не только на ошибки.
Правило 2: Комментируйте код, а не человека
Вместо «Ты написал ужасный цикл» напишите: «Этот цикл можно заменить на Array.map() для большей читаемости». Говорите о коде, а не о личности.
Правило 3: Объясняйте «почему»
Не просто пишите «исправь на const», а объясните: «Использование const предотвращает случайное переопределение переменной и делает намерение явным». Это помогает новичку понять принцип.
Правило 4: Используйте вопросы вместо утверждений
Вместо «Этот код небезопасен» спросите: «Что произойдет, если сюда передать отрицательное число? Стоит ли добавить валидацию?» Это стимулирует мышление.
Правило 5: Разделяйте критику и задачу
Если изменений много, не требуйте всё исправить в одном пулл-реквесте. Разделите на «критические» (баги, уязвимости) и «улучшения» (стиль, рефакторинг). Критические — блокируют мерж, улучшения — можно отложить.
Пример code review в действии
Предположим, коллега прислал такой код для Node.js:
function processUsers(users) {
let result = [];
for (let i = 0; i < users.length; i++) {
if (users[i].active) {
result.push(users[i].name);
}
}
return result;
}
Ваш комментарий может выглядеть так:
- Позитив: «Хорошо, что ты проверяешь поле
active— это предотвращает включение неактивных пользователей». - Улучшение (вопрос): «Как думаешь, можно ли заменить цикл на
filterиmap? Это сделает код более декларативным и легким для чтения. Например:users.filter(u => u.active).map(u => u.name)». - Критическое (если есть): «Что будет, если
users—null? Стоит добавить проверку в начале функции».