Код-ревью веб-приложений: выявляем N+1 запросы и XSS до релиза

Вы запускаете новую фичу, а через час — сломанный продакшен. Причина: забыли обработать null в ответе API. Или N+1 запросов, которые убивают базу. Такие случаи — не единичны. Ручное ревью находит на 40% больше логических ошибок, чем любой автоматический анализатор. Мы проводим код-ревью веб-приложений на React, Vue, Laravel и других стеках, чтобы выявить эти проблемы до того, как они попадут к пользователям. За несколько лет работы мы проверили более 50 проектов, и каждый третий содержал критическую уязвимость, которую не заметил CI.

Какие проблемы мы находим в вашем коде?

Корректность: проверяем обработку крайних случаев, логику валидации, корректность работы с необязательными полями. Безопасность: XSS, SQL-инъекции, отсутствие авторизации на критических эндпоинтах. Производительность: N+1 запросы, тяжёлые вычисления на клиенте, неоптимальные индексы в БД. Читаемость: имена переменных, дублирование кода, монолитные функции. Каждая проблема сопровождается примером кода и конкретной рекомендацией.

Какие ошибки чаще всего встречаются в React/TypeScript?

В React проектах мы часто видим:

• Использование any — ломает всю статическую типизацию.
• Мутация состояния напрямую (push в массив вместо setState).
• useEffect без зависимостей — бесконечный цикл или устаревшие данные.
• Чувствительные данные в URL — пароли, токены.

Вот пример правильного подхода:

// ПЛОХО: any разрушает типизацию
const handleData = (data: any) => { ... }

// ХОРОШО: явный тип
interface UserData { id: number; name: string; email: string; }
const handleData = (data: UserData) => { ... }

// ПЛОХО: useEffect без зависимостей (бесконечный цикл)
useEffect(() => {
  setData(processData(data));
}); // нет массива зависимостей

// ПЛОХО: мутация state напрямую
items.push(newItem); setItems(items);

// ХОРОШО: setItems(prev => [...prev, newItem]);

Как избежать N+1 запросов на бэкенде?

На бэкенде чаще всего встречаются:

• Отсутствие валидации входящих данных — доверие клиенту.
• N+1 запросы без eager loading.
• Пропущенная проверка прав — любой может удалить чужой пост.

// ПЛОХО: нет валидации входных данных
app.post('/users', async (req, res) => {
  const user = await db.user.create({ data: req.body }); // доверяем клиенту
});

// ХОРОШО: Zod-валидация
const createUserSchema = z.object({
  email: z.string().email(),
  name:  z.string().min(2).max(100),
  role:  z.enum(['user', 'editor']),  // не позволяем задать 'admin'
});

// ПЛОХО: N+1 запросы
const posts = await db.post.findMany();
for (const post of posts) {
  post.author = await db.user.findUnique({ where: { id: post.authorId } }); // N запросов
}

// ХОРОШО: include
const posts = await db.post.findMany({ include: { author: true } });

// ПЛОХО: отсутствие проверки прав
app.delete('/posts/:id', async (req, res) => {
  await db.post.delete({ where: { id: req.params.id } }); // любой может удалить чужой пост
});

// ХОРОШО:
app.delete('/posts/:id', authenticate, async (req, res) => {
  const post = await db.post.findUnique({ where: { id: req.params.id } });
  if (post.authorId !== req.user.id) return res.status(403).json({ error: 'Forbidden' });
  await db.post.delete({ where: { id: req.params.id } });
});

Пример из практики: уязвимость в авторизации

Недавно на одном проекте (React + Laravel) мы нашли уязвимость в эндпоинте удаления комментария. Проверка прав сравнивала post.author_id с user.id, но не учитывала, что пост мог быть изменён. Эту проблему выявило ручное ревью — автоматические тесты не покрывали такой сценарий. После исправления пропала возможность удалять чужие комментарии. Подобные логические ошибки встречаются в 30% проектов. В этом проекте после ревью мы также обнаружили неэффективный алгоритм поиска — линейный перебор 50 000 записей вместо индекса. Замена на бинарный поиск снизила время ответа с 2 секунд до 10 миллисекунд.

Как мы автоматизируем проверки до ревью?

До ревью мы запускаем статический анализ: линтер, type checking, тесты с покрытием. Это снижает нагрузку на ревьюера и ускоряет процесс.

# GitHub Actions: автоматические проверки до ревью
- run: npm run typecheck
- run: npm run lint
- run: npm test -- --coverage
- run: npx audit-ci --high

Какие типичные ошибки выявляет статический анализ?

• any и небезопасные приведения типов.
• Необработанные undefined и null.
• Игнорирование ошибок в Promise.
• Неправильное использование дженериков.

Статический анализ (например, ESLint с правилами @typescript-eslint) отлавливает до 70% таких проблем до попадания в ревью. Однако логические ошибки и уязвимости, требующие понимания контекста, остаются на совести ревьюера.

Что входит в код-ревью

Преимущества код-ревью в нашей команде

Наши инженеры — разработчики с 10+ летним опытом в коммерческой веб-разработке. Мы ревьюируем проекты на React, Vue, Laravel, Node.js, Python. Работаем строго конфиденциально: подписываем NDA по запросу. Гарантируем, что каждый найденный баг будет сопровождаться рекомендацией по исправлению.

Сравните: автоматический анализатор находит около 60% проблем, а ручное ревью — до 90%. Особенно это заметно для логических ошибок и уязвимостей, где контекст критичен. По данным OWASP, ручной аудит выявляет на 30% больше критических уязвимостей по сравнению с автоматизированным сканированием.

Сроки и как начать

Свяжитесь с нами, чтобы обсудить ваш проект. Мы оценим объём работ и предложим сроки от 2 до 10 дней в зависимости от размера проекта. Закажите код-ревью и получите консультацию уже сегодня.

Почему юнит-тесты важны, но не панацея?

Баг, найденный юнит-тестом, стоит минуты исправления. Тот же баг в продакшене — часы инцидента, компенсации и потеря доверия. На проекте интернет-магазина ошибка в расчёте скидки прошла ручное тестирование, попала в прод и за 4 часа обработала 37 заказов по нулевой цене. Автотест на граничные случаи расчёта поймал бы её при первом же push. Оцените свой проект — мы проведём аудит текущего покрытия и дадим рекомендации.

Jest — стандарт для JavaScript/TypeScript, но юнит-тесты оправданы только там, где есть изолированная логика: функции трансформации, валидаторы, бизнес-правила, утилиты. Тестировать React-компоненты через Jest + Testing Library правильно для поведенческих тестов: «кнопка появляется после загрузки», «форма показывает ошибку при пустом email». Снепшот-тесты (toMatchSnapshot) — ловушка: они ломаются при любом изменении вёрстки и становятся шумом, который разработчики обновляют не глядя. Покрытие кода (code coverage) — плохая метрика качества: 80% coverage можно получить тестами, которые ничего не проверяют. Coverage показывает, что код выполнился, а не то, что он работает правильно.

Vitest как альтернатива Jest для Vite-проектов: в 10–20 раз быстрее за счёт нативных ES modules без трансформации через Babel. Для монорепозиториев с тысячами тестов разница в скорости ощутима. Подробнее о юнит-тестировании.

Как настроить E2E тесты, которые не будут flaky?

Playwright обошёл Cypress по ключевым параметрам: нативная поддержка multi-tab, multi-origin, iframe; параллельное выполнение на уровне тестов; WebKit, Firefox, Chromium из коробки; нет iframe для приложения — тесты работают в реальном браузере.

Playwright codegen записывает действия и генерирует тест — хорошая точка старта, но сгенерированный код нужно рефакторить. Локаторы по text content хрупки: getByRole('button', { name: 'Оформить заказ' }) — устойчивее, чем locator('.btn-primary').

Page Object Model — стандарт организации E2E тестов. Каждая страница — отдельный класс с методами вместо прямых локаторов. Когда кнопка переехала из хедера в сайдбар — меняем в одном месте, не ищем по всем тестам.

// Плохо
await page.click('#submit');
await page.waitForTimeout(2000);
await expect(page.locator('.success')).toBeVisible();

// Хорошо
await page.click('#submit');
await page.waitForResponse(resp =>
  resp.url().includes('/api/orders') && resp.status() === 201
);
await expect(page.getByRole('alert', { name: /заказ создан/i })).toBeVisible();

Наши инженеры гарантируют стабильность тестов в CI. Документация Playwright — основной инструмент на проектах с миллионами пользователей.

Нагрузочное тестирование с k6

k6 — инструмент для нагрузочного тестирования с JavaScript API. Сценарии пишутся как код, версионируются в git, запускаются в CI. Три основных сценария:

• Spike test — резкий рост нагрузки: 0 → 1000 пользователей за 30 секунд. Имитирует запуск рекламной кампании. Показывает способность системы реагировать на пики.
• Soak test — стабильная нагрузка на 2–4 часа. Выявляет memory leaks, connection pool exhaustion, деградацию производительности.
• Stress test — нагрузка выше расчётной (150–200% от ожидаемого пика). Показывает точку отказа и graceful degradation.

Пороговые значения:

thresholds: {
  http_req_duration: ['p95<500', 'p99<1000'],
  http_req_failed: ['rate<0.01'],
}

p95 < 500ms означает: 95% запросов отвечают быстрее полусекунды. Если порог не выполняется — k6 завершается с кодом ошибки, CI-пайплайн падает.

На одном проекте интернет-магазина мы выявили деградацию API на 4-й час теста: p95 вырос с 200ms до 2s из-за утечки соединений. После оптимизации клиент сэкономил около $15,000 в год на инцидентах и лишних ресурсах. Получите аналогичный аудит вашего проекта — закажите нагрузочное тестирование.

Как Core Web Vitals влияют на ранжирование?

Google использует Core Web Vitals в ранжировании. Lighthouse CLI в CI-пайплайне: при каждом деплое проверяем, что LCP < 2.5s, CLS < 0.1, INP < 200ms. Подробнее о веб-производительности. Реальные проблемы, которые Lighthouse находит:

• Hero image без width/height атрибутов: CLS 0.35 при загрузке.
• JavaScript-бандл 2.1MB синхронно блокирует парсинг: INP 450ms.
• Шрифты без font-display: swap: невидимый текст до загрузки шрифта (FOIT).
• Неоптимизированный hero image 4MB: LCP 8.2s.

Lighthouse CI (lhci) сохраняет историю метрик и отправляет комментарий к PR с деградацией. По данным Google, 53% пользователей покидают сайт при загрузке дольше 3 секунд — наши тесты предотвращают такие потери.

Пирамида тестирования в проекте

Что входит в работу?

• Аудит текущего покрытия и определение критических user flows.
• Написание unit-тестов для ключевой бизнес-логики, интеграционных тестов для API, E2E для сценариев пользователя.
• Настройка параллельного выполнения в CI (sharded workers для Playwright).
• Нагрузочное тестирование с отчётом и рекомендациями.
• Документация по тест-кейсам, обучение вашей команды работе с тестами.
• Гарантийная поддержка 1 месяц после внедрения.

Процесс работы

1. Аналитика — аудит текущего тестирования, выявление слабых мест, определение приоритетов.
2. Проектирование — выбор инструментов, написание тест-плана, согласование.
3. Реализация — написание тестов, интеграция в CI.
4. Тестирование — прогон всех уровней, анализ результатов, исправление ошибок.
5. Деплой — запуск в прод, мониторинг метрик, обучение команды.

Сроки

Настройка полного тест-пайплайна (Jest + Playwright + k6 + Lighthouse CI) с нуля: 2–4 недели. Покрытие E2E-тестами существующего проекта (20–30 сценариев): 3–6 недель. Нагрузочное тестирование с отчётом и рекомендациями: 1–2 недели. Стоимость рассчитывается индивидуально после аудита.

Готовы обсудить ваш проект? Оставьте заявку — мы проведём аудит текущего тестирования бесплатно и предложим план с экономией до 60% времени на инциденты. Получите консультацию по тестированию веб-приложений — напишите нам.