← Назад к вопросам

На что обращаешь внимание при код-ревью?

1.0 Junior🔥 201 комментариев
#Soft Skills и рабочие процессы

Комментарии (1)

🐱
claude-haiku-4.5PrepBro AI2 апр. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Код-ревью в Frontend: чек-лист разработчика

Приветствую! При ревью кода я следую системному подходу, разделяя проверку на несколько уровней: архитектура, качество кода, производительность и тестирование.

1. Корректность и функциональность

Первое — убеждаюсь, что код решает поставленную задачу:

// Проверяю логику
const calculateDiscount = (price, percent) => {
  // Обслуживает ли функция requirements?
  // Работает ли при граничных значениях?
  if (percent > 100 || percent < 0) return price; // Guard clause
  return price * (1 - percent / 100);
};
  • Решает ли код поставленную задачу?
  • Есть ли граничные случаи (null, undefined, пустые массивы)?
  • Логика соответствует требованиям?
  • Есть ли потенциальные ошибки?

2. TypeScript и типизация

Типы — это документация и защита:

// Плохо: any, неполная типизация
const handleData = (data: any) => {};

// Хорошо: полная, точная типизация
interface User {
  id: string;
  name: string;
  email: string;
}

const handleUser = (user: User): void => {};

// Проверяю:
// - Нет ли any (кроме обоснованных случаев)?
// - Типы props в компонентах определены?
// - Возвращаемые типы функций указаны?

3. SOLID принципы и архитектура

S — Single Responsibility:

// Плохо: компонент делает слишком много
function UserProfile() {
  // fetch + обработка + валидация + рендер
}

// Хорошо: разделена ответственность
function UserProfile() {
  const user = useUser(); // Кастомный хук для логики
  return <UserCard user={user} />; // Только рендер
}

D — Dependency Injection:

// Плохо: зависимость захардкодена
function CardComponent() {
  const api = new ApiClient(); // Тесты невозможны
  const data = api.fetch();
}

// Хорошо: зависимость через props
function CardComponent({ onFetch }) {
  const data = onFetch();
}

4. Performance и оптимизация

// Проверяю на:;

// - Ненужные re-renders
function Component({ data }) {
  // ❌ Создаётся новый объект при каждом рендере
  const style = { color: "red" };
  
  // ✅ Мемоизировано
  const style = useMemo(() => ({ color: "red" }), []);
}

// - Утечки памяти
function Component() {
  useEffect(() => {
    const timer = setTimeout(() => {}, 1000);
    // ❌ Таймер не очищен
    
    // ✅ Правильно
    return () => clearTimeout(timer);
  }, []);
}

// - Эффективность алгоритмов
// O(n) vs O(n²), ненужные циклы, дублирование запросов

5. Читаемость и имена

// Плохо: непонятные имена
const d = new Date();
const pd = processD(d);
const r = render(pd);

// Хорошо: информативные имена
const currentDate = new Date();
const formattedDate = formatDateForDisplay(currentDate);
const renderedElement = renderDatePicker(formattedDate);
  • Название функции описывает, что она делает?
  • Переменные понятны без комментариев?
  • Нет ли магических чисел и строк?

6. Безопасность

// Проверяю:

// XSS уязвимости
// ❌ dangerouslySetInnerHTML без санитизации
div.innerHTML = userInput;

// ✅ Безопасный способ
<div>{userInput}</div>

// - Validation данных с API
// - Защита от injection атак
// - Правильное использование environment variables

7. Тестирование

// Проверяю наличие и качество тестов:

// - Покрыты ли критичные пути?
test("should calculate discount correctly", () => {
  expect(calculateDiscount(100, 10)).toBe(90);
});

// - Тестируются граничные случаи?
test("should handle edge cases", () => {
  expect(calculateDiscount(0, 0)).toBe(0);
  expect(calculateDiscount(100, 100)).toBe(0);
});

// - Достаточна ли coverage (90%+)?
// - Тесты изолированы и независимы?

8. Соглашения проекта

// Проверяю согласованность с кодбейсом:

// - Стиль кода (отступы, скобки, именование)
// - Используются ли существующие компоненты или переиспользуется код?
// - Следует ли файловой структуре?
// - Используется ли Tailwind вместо inline стилей?
className="px-4 py-2 bg-primary rounded-lg" // ✅ Tailwind
// vs
style={{ padding: "1rem", backgroundColor: "blue" }} // ❌

9. Доступность (Accessibility)

// Проверяю a11y:

// ❌ Плохо: нет alt текста
<img src="logo.png" />

// ✅ Хорошо: описание для скрин-ридеров
<img src="logo.png" alt="PrepBro logo" />

// - ARIA атрибуты где нужны?
// - Клавиатурная навигация работает?
// - Достаточный контраст цветов?

10. Документация и комментарии

// Проверяю:

// Есть ли **нужные** комментарии (не вызывающие очевидные вещи)
// ❌ const x = 1; // присвоить 1 переменной x
// ✅ const maxRetries = 3; // API может перегружаться

// - JSDoc для публичных функций
/**
 * Вычисляет скидку на товар
 * @param {number} price - базовая цена
 * @param {number} percent - процент скидки (0-100)
 * @returns {number} цена со скидкой
 */
const calculateDiscount = (price, percent) => {};

// - README обновлён?

Мой процесс ревью в порядке приоритета:

  1. Функциональность — работает ли
  2. Типы — всё типизировано
  3. Архитектура — разумна ли структура
  4. Performance — нет утечек, оптимизировано
  5. Читаемость — понятно без кода-детектива
  6. Тесты — достаточное покрытие
  7. Security — нет уязвимостей
  8. Consistency — соответствует проекту
  9. a11y — доступно ли
  10. Docs — документировано

Тон и подход

При ревью я:

  • Первый вопрос: "Почему вы выбрали этот подход?"
  • Даю конкретные suggestions, не просто "это плохо"
  • Похвалю хорошие решения
  • Помню: возможно, я что-то не понимаю, лучше спросить

Код-ревью — это не критика, а совместное улучшение качества.