Код-рев'ю веб-застосунків: виявляємо 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 через витік з'єднань. Після оптимізації клієнт заощадив значну суму на інцидентах та зайвих ресурсах. Отримайте аналогічний аудит вашого проекту — замовте навантажувальне тестування.

Як 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% часу на інциденти. Отримайте консультацію з тестування веб-додатків — напишіть нам.