Code review в TypeScript: что проверять и как давать обратную связь

Введение: зачем нужно code review в TypeScript?

Code review — это не просто формальная проверка кода перед мержем. Это мощный инструмент для повышения качества проекта, обмена знаниями в команде и предотвращения багов на ранних этапах. Когда речь идет о TypeScript, code review приобретает особое значение: статическая типизация, мощная система дженериков и строгие настройки компилятора позволяют отловить множество ошибок еще до запуска приложения. Однако даже в TypeScript есть подводные камни, которые легко пропустить.

В этой статье мы разберем, на что обращать внимание при ревью TypeScript-кода, и как давать обратную связь так, чтобы она была полезной, а не обидной.

1. Типизация и дженерики: не дайте any всё испортить

Одна из главных целей TypeScript — сделать типы явными. Если в коде встречается any, это почти всегда красный флаг. При code review проверяйте:

• Отсутствие any. Замените его на unknown с последующей проверкой типа или на конкретный тип.
• Корректность дженериков. Убедитесь, что параметры типов не теряются и не становятся слишком широкими. Например:

// Плохо: теряем тип
function getFirst(arr: any[]): any {
    return arr[0];
}

// Хорошо: сохраняем тип через дженерик
function getFirst<T>(arr: T[]): T | undefined {
    return arr[0];
}

• Типизация API-ответов. Если приходит JSON с сервера, он должен быть описан интерфейсом, а не any.
• Utility types. Используйте Partial, Pick, Omit для гибкой работы с объектами — это уменьшает дублирование кода.

Совет: включите в tsconfig.json флаг strict: true и noImplicitAny: true — это отсечёт большинство проблем на уровне компиляции.

2. Логика и обработка ошибок: не молчите о проблемах

TypeScript не защищает от логических ошибок, поэтому code review должен проверять бизнес-логику и обработку исключений.

Что смотреть:

• Обработка граничных случаев. Что произойдёт, если массив пуст, объект null или строка пустая? Пример:

// Плохо: не проверяем наличие элемента
function getUserName(users: User[], id: string): string {
    return users.find(u => u.id === id)!.name; // может упасть с ошибкой
}

// Хорошо: проверяем
function getUserName(users: User[], id: string): string | null {
    const user = users.find(u => u.id === id);
    return user ? user.name : null;
}

• Асинхронные операции. Убедитесь, что промисы корректно обрабатываются через async/await, а ошибки ловятся в try/catch.
• Избегание мутаций. Если функция не должна менять входные данные, используйте readonly и иммутабельные методы (например, map вместо forEach с изменением внешнего массива).

3. Стиль кода и читаемость: код пишется для людей

Даже идеально типизированный код может быть нечитаемым. Code review — отличный момент для обсуждения стиля.

Основные моменты:

• Именование. Переменные, функции и классы должны говорить о своей цели. Избегайте однобуквенных названий (кроме индексов циклов). Пример: fetchUserData лучше, чем getData.
• Размер функций. Функция не должна делать больше одной вещи. Если она длиннее 20-30 строк — это повод задуматься о рефакторинге.
• Комментарии. Комментарии должны объяснять почему код написан так, а не что он делает. Если комментарий дублирует код — удалите его.
• Форматирование. Используйте линтер (ESLint) и форматтер (Prettier), чтобы не тратить время на обсуждение пробелов и точек с запятой.

Пример плохого стиля:

function f(x: number, y: number): boolean {
    // проверка
    if (x > y) {
        return true;
    } else {
        return false;
    }
}

Лучше:

function isGreaterThan(a: number, b: number): boolean {
    return a > b;
}

4. Как давать обратную связь: конструктивно и без обид

Code review — это диалог, а не монолог. Чтобы ревью приносило пользу, а не демотивировало, следуйте этим правилам:

• Начинайте с позитива. Отметьте, что сделано хорошо: «Отличное использование дженериков!» или «Красивое решение с reduce».
• Формулируйте как предложение, а не приказ. Вместо «Перепиши это» скажите: «А что если использовать map вместо цикла? Это упростит чтение».
• Объясняйте причину. Если просите исправить что-то, объясните, почему это важно. Например: «Здесь any может привести к runtime-ошибке, лучше использовать конкретный тип».
• Используйте вопросы. «Ты уверен, что этот случай обработан?» или «Почему выбран enum, а не union type?» — такие вопросы стимулируют обсуждение.
• Не критикуйте человека, критикуйте код. Вместо «Ты написал плохой код» скажите «Этот участок кода может быть улучшен».

Помните: цель ревью — улучшить код, а не самоутвердиться за чужой счет.

Заключение

Code review в TypeScript — это не просто формальность, а способ сделать код надежнее, чище и понятнее для всей команды. Используйте чек-лист: проверяйте типиза