Как понять что код готов для отправки на Code Review?

Как понять что код готов для отправки на Code Review?

Это критический вопрос о качестве и профессионализме разработчика. Готовность кода к Code Review — это не просто наличие функционала, а соответствие стандартам проекта и способность кода работать в продакшене. Давайте разберём ключевые критерии.

1. Функциональность и тесты

Код должен работать корректно:

• Реализован весь требуемый функционал из задачи
• Нет очевидных bagов и ошибок
• Граничные случаи обработаны
• Обработка ошибок реализована

Покрытие тестами:

// ✅ Функция с тестами
function calculateDiscount(price, percent) {
  if (price < 0) throw new Error('Invalid price');
  if (percent < 0 || percent > 100) throw new Error('Invalid percent');
  return price * (1 - percent / 100);
}

// Тесты
test('calculates discount correctly', () => {
  expect(calculateDiscount(100, 20)).toBe(80);
});

test('throws on invalid price', () => {
  expect(() => calculateDiscount(-10, 20)).toThrow();
});

Цель: минимум 80-90% покрытия для новых фич.

2. Качество кода

Читаемость и понятность:

// ❌ Плохо — непонятно
const f = (d) => d.m.f(x => x.s > 100).m(y => y.p);

// ✅ Хорошо — понятно
const highValueOrders = orders
  .filter(order => order.subtotal > 100)
  .map(order => order.products);

Следование стилю проекта:

• Код прошел линтер (npm run lint)
• Форматирование соответствует Prettier/ESLint
• Нет console.log и debug кода
• Нет TODO без контекста

// ❌ Перед Code Review
const result = someFunc(); // TODO: fix this
console.log('DEBUG:', result);

// ✅ После подготовки
const result = someFunc();
// Обработка результата

3. Архитектура и структура

Компонент должен быть:

• Модульным и переиспользуемым
• Не содержать боковых эффектов
• Иметь четкую зону ответственности

// ❌ Монолит — тяжело тестировать
export function UserProfile() {
  const [user, setUser] = useState(null);
  useEffect(() => {
    fetch('/api/user')
      .then(r => r.json())
      .then(data => {
        setUser(data);
        localStorage.setItem('user', JSON.stringify(data));
        analytics.track('user_loaded');
      });
  }, []);
  return <div>{user?.name}</div>;
}

// ✅ Разделено — легко тестировать
function useUser() {
  const [user, setUser] = useState(null);
  useEffect(() => {
    fetchUser().then(setUser);
  }, []);
  return user;
}

export function UserProfile() {
  const user = useUser();
  return <div>{user?.name}</div>;
}

4. Типизация (TypeScript)

Все типизировано:

// ❌ Плохо
function processData(data: any) {
  return data.name.toUpperCase();
}

// ✅ Хорошо
interface User {
  name: string;
  email: string;
}

function processUser(user: User): string {
  return user.name.toUpperCase();
}

5. Производительность

Оптимизирована ли:

• Нет лишних re-renders (используй useMemo, useCallback)
• Нет утечек памяти
• Нет N+1 запросов к API
• Размер бундля не растет существенно

// ❌ Лишние re-renders
const handleClick = () => { /* ... */ };
return <Child onClick={handleClick} />; // Создает новую функцию каждый раз

// ✅ Оптимизировано
const handleClick = useCallback(() => { /* ... */ }, []);
return <Child onClick={handleClick} />;

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

Проверки:

• Нет XSS уязвимостей
• Санитизирован пользовательский ввод
• Нет хардкодированных секретов
• Используются безопасные методы (dangerouslySetInnerHTML избегать)

// ❌ XSS уязвимость
<div dangerouslySetInnerHTML={{ __html: userInput }} />

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

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

Код должен быть самодокументирующимся:

// ✅ JSDoc для сложных функций
/**
 * Преобразует пользовательские данные в формат API
 * @param {User} user - Объект пользователя
 * @returns {UserDTO} - DTO для отправки на сервер
 */
function transformUserToDTO(user: User): UserDTO {
  // ...
}

// Комментарии для нетривиального логика
const result = items.filter(x => x.active)  // Получаем только активные
                   .map(x => x.value);      // Извлекаем значения

8. Git история

Коммиты должны быть:

• Логичными и атомарными
• С понятными сообщениями
• Без merge commits (используй rebase)

# ❌ Плохо
git commit -m 'fix'
git commit -m 'stuff'

# ✅ Хорошо
git commit -m 'feat(auth): add login form validation'
git commit -m 'fix(button): remove console.log from click handler'

9. Локальное тестирование

Перед отправкой:

# Все тесты проходят
npm run test

# Линтер доволен
npm run lint

# Сборка успешна
npm run build

# Проверяешь в браузере
npm run dev

10. Code Review Checklist

Проверь перед отправкой:

• Функционал полностью работает
• Тесты написаны и проходят
• Нет console.log и debug кода
• Код следует стилю проекта
• TypeScript errors исправлены
• Нет дублирования (DRY)
• Производительность оптимальна
• Документация добавлена
• Git история понятная
• Все тесты зелены: npm run test, npm run lint

Практический совет

Один час на подготовку кода к CR сэкономит несколько часов на исправления замечаний. Качественный код — это признак профессионала.

Вывод: Код готов к Code Review когда он функционален, протестирован, соответствует стандартам проекта и готов к production. Это не только о наличии функционала, но и о качестве, безопасности, производительности и поддерживаемости кода.