Що таке технічний аудит коду і коли він потрібен.

Технічний аудит коду — це незалежна перевірка вихідного коду, архітектури та інфраструктури проєкту, результатом якої є звіт: що працює добре, що небезпечно чи повільно, і в якому порядку це виправляти. Він потрібен, коли ви успадковуєте проєкт, змінюєте підрядника, готуєтеся до масштабування чи продажу бізнесу або просто не розумієте, чому кожна нова фіча коштує дорожче за попередню.

Нижче — що саме ми перевіряємо в Laravel-проєктах, як виглядає звіт, які сигнали вказують, що час замовляти аудит, і чого від нього не варто очікувати.

Що таке технічний аудит і чим він не є

Аудит — це діагностика, а не лікування. Експерт читає код, запускає проєкт, дивиться на базу даних, залежності, конфігурацію, процес розгортання й складає документ із висновками. Виправлення — окремий етап, який ви можете віддати будь-якій команді, а не обов'язково тій, що проводила аудит.

Аудит коду відрізняється від суміжних послуг:

• QA-тестування перевіряє поведінку продукту очима користувача: чи працює кошик, форма, оплата. Це QA-аудит інтернет-магазину. Код при цьому не читається.
• Код-рев'ю оцінює конкретні зміни (pull request) в процесі розробки.
• Пентест — цілеспрямована спроба зламати систему. Ми проводимо перевірку безпеки на рівні коду й конфігурації, але не заявляємо про повний пентест.
• Технічний аудит охоплює проєкт цілком: структуру, якість, безпеку, продуктивність, процеси.

Найкращий результат дають обидва підходи разом: QA знаходить симптоми, аудит коду — причини.

Сигнали, що аудит вам потрібен

Не кожен проєкт потребує аудиту щороку. Є ситуації, коли це особливо виправдано.

1. Змінюється команда. Новий підрядник чи тех-лід має швидко зрозуміти, що саме він отримує, перш ніж брати відповідальність.
2. Нові фічі дорожчають і довго робляться. Розробники кажуть «там усе переплетено» — це класичний симптом технічного боргу.
3. Сайт повільний або падає під навантаженням. Особливо в сезонні піки: акції, розпродажі.
4. Після інциденту. Витік даних, злам адмінки, втрата замовлень.
5. Перед великими змінами. Міграція на нову версію фреймворку, масштабування, інтеграція з CRM або 1С.
6. Перед продажем або інвестиціями. Покупець чи інвестор хоче бачити стан активу.
7. Ви не довіряєте оцінкам підрядника. Незалежна думка допоможе зрозуміти, чи справді «це треба переписати».

Якщо хоча б два пункти вам знайомі, аудит окупиться швидше, ніж ви витратите гроші на нову порцію виправлень «навмання».

Що ми перевіряємо в Laravel-проєкті

Архітектура і якість коду

Перше, що ми дивимося, — де живе бізнес-логіка. У здоровому проєкті контролер тонкий: валідація, виклик сервісу, відповідь. У нездоровому — контролер на 600 рядків із розрахунком знижок, відправкою листів і роботою з платіжкою.

Ми перевіряємо:

• розподіл відповідальності: контролери, сервіси, Form Request, Policy, Job;
• дублювання коду та «божественні» класи;
• залежності між модулями й циклічні зв'язки;
• відповідність фреймворку: чи не обходять його механізми власними велосипедами;
• покриття тестами й відтворюваність: чи проходять тести, чи є CI.

Типовий приклад проблеми, яку ми описуємо у звіті:

// OrderController.php — логіка в контролері
public function store(Request $request)
{
    $total = 0;
    foreach ($request->items as $item) {
        $product = Product::find($item['id']);      // запит у циклі
        $total += $product->price * $item['qty'];
    }
    if ($request->promo === 'SALE10') {            // «магічне» значення
        $total *= 0.9;
    }
    $order = Order::create([...]);
    Mail::to($request->email)->send(new OrderMail($order)); // синхронна відправка
}

У звіті це перетворюється на конкретні пункти: винести розрахунок у сервіс, завантажувати товари одним запитом, промокоди зберігати в базі, лист відправляти через чергу.

Безпека

Для Laravel ми перевіряємо базові, але критичні речі, які часто пропускають:

• APP_DEBUG=true на продакшені та витік змінних середовища;
• масове присвоєння ($guarded = []) і відсутність перевірки прав доступу в контролерах;
• SQL-ін'єкції через сирі запити (DB::raw, whereRaw з конкатенацією);
• XSS через вивід неекранованих даних ({!! !!});
• завантаження файлів без перевірки типу й розміру;
• CSRF, налаштування cookie, заголовки безпеки;
• застарілі пакети з відомими вразливостями (composer audit);
• зберігання секретів у репозиторії та історії git.

Небезпечний приклад, який трапляється частіше, ніж хотілося б:

// пошук у адмінці: ін'єкція через конкатенацію
$orders = DB::select("SELECT * FROM orders WHERE email = '" . $request->email . "'");

// правильно: прив'язка параметрів
$orders = DB::select('SELECT * FROM orders WHERE email = ?', [$request->email]);

Окремо дивимося на персональні дані покупців: що зберігається, хто має доступ, чи є резервні копії та журналювання. Це не юридичний висновок, а технічна оцінка ризиків.

Продуктивність і база даних

Більшість повільних Laravel-сайтів страждають від кількох повторюваних проблем:

• N+1 запити. Список із 50 товарів породжує 150 запитів до бази, бо зв'язки підвантажуються по одному. Лікується with(), але спочатку це треба знайти.
• Відсутні індекси на колонках, за якими фільтрують і сортують.
• Важкі запити в кожному запиті сторінки: лічильники, підсумки, які можна кешувати.
• Синхронна робота з зовнішніми API в основному потоці: Нова Пошта, платіжка, листи.
• Відсутнє кешування конфігурації, маршрутів, результатів дорогих обчислень.

Ми вмикаємо журнал запитів на тестовому середовищі, проходимо ключові сценарії (каталог, картка товару, кошик, checkout) і фіксуємо кількість запитів та час відповіді. Для виявлення N+1 дуже допомагає заборона «лінивого» завантаження в нерелізному середовищі:

// AppServiceProvider::boot()
Model::preventLazyLoading(! app()->isProduction());

Після цього будь-яка неоптимальна вибірка падає з помилкою ще на розробці. У звіті ми показуємо до/після в цифрах, а не загальні слова про «оптимізацію».

База даних і дані

Перевіряємо схему: чи відтворюється вона міграціями з нуля, чи є зовнішні ключі та обмеження унікальності, як зберігаються гроші (цілі числа в копійках або decimal, але не float), чи немає «сміттєвих» таблиць і дублікатів. Для магазину особливо важливі статуси замовлень, склад і ціни: тут помилки коштують грошей.

Залежності й підтримуваність

Версія PHP, версія Laravel, статус підтримки, пакети без оновлень кілька років. Ми не радимо «оновити все одразу», а будуємо реалістичний план: що критично (вразливості), що бажано, що можна відкласти.

Інфраструктура й процес розгортання

• Як проєкт розгортається: вручну по FTP чи автоматично з перевіркою тестів?
• Чи є середовище стейджингу, відмінне від продакшену?
• Резервні копії: чи їх хтось колись відновлював?
• Моніторинг помилок і доступності: дізнаєтеся ви про збій від системи чи від клієнта?
• Журнали та алерти.

Резервна копія, яку жодного разу не відновлювали, — гіпотеза, а не копія. Ми це перевіряємо в першу чергу.

Як виглядає результат аудиту

Хороший звіт відповідає на три питання: що не так, наскільки це критично і що робити першим. Ми структуруємо його так:

Ми не пишемо «код погано» чи «код добре». Кожна знахідка прив'язана до файлу чи сценарію, а пріоритет — до наслідків: «ця вразливість дозволяє переглядати чужі замовлення», «цей запит уповільнює каталог у п'ять разів».

Саме пріоритизація відрізняє корисний аудит від переліку зауважень на 80 сторінок. Власник бізнесу не зобов'язаний усе виправляти, але має знати, що саме горить, а що можна лишити.

Потрібен аудит вашого Laravel-проєкту? Ми перевіряємо архітектуру, безпеку й продуктивність і передаємо звіт із планом виправлень за 5–7 днів. Вартість — від 12 000 грн, деталі на сторінці технічного аудиту коду.

Скільки це коштує і скільки триває

Вартість залежить від розміру кодової бази, кількості інтеграцій та глибини перевірки. На сторінці тарифів технічний аудит Laravel-проєкту коштує 12 000–25 000 грн залежно від обсягу, термін — 5–7 днів. Точну суму ми називаємо після короткого огляду проєкту: розміру репозиторію, кількості моделей і маршрутів, наявності тестів.

Чинники, що збільшують обсяг:

• велика кількість інтеграцій (оплата, доставка, CRM, 1С);
• відсутність документації та тестів, доводиться розбиратися «з нуля»;
• кілька застосунків (бекенд, фронтенд на Nuxt, мобільний клієнт);
• стара версія фреймворку з нестандартними патчами.

Для консультації без повного аудиту є формат Tech Lead на годину: 90 хвилин розмови, огляд архітектури та відповіді на конкретні питання.

Що потрібно підготувати для аудиту

Щоб аудит пройшов швидко й без зайвих пауз, надайте:

1. Доступ до репозиторію лише на читання (або архів коду).
2. Копію бази даних без персональних даних або доступ до тестового середовища.
3. Опис проєкту: що робить, хто користувачі, які сценарії найважливіші для бізнесу.
4. Перелік інтеграцій і зовнішніх сервісів.
5. Відомі проблеми: що повільно, що ламається, що лякає розробників.
6. Інформацію про інфраструктуру: хостинг, спосіб розгортання, моніторинг.

Секрети (ключі API, паролі) не потрібні: ми працюємо з знеособленими або тестовими значеннями. Підписати угоду про нерозголошення можна до отримання коду.

Що робити зі звітом далі

Після аудиту у вас є три шляхи:

• Виправити власними силами або силами поточної команди. Звіт слугує технічним завданням.
• Віддати виправлення нам. Фікс-пакет рахується за ставками від $20–35 за годину за обсягом знайденого.
• Використати звіт як аргумент у розмові з підрядником або при виборі нового. Про це читайте в статті як обрати підрядника на розробку сайту.

Поширена помилка — спробувати виправити все одразу. Краще піти за пріоритетами: спочатку безпека й втрата грошей, потім продуктивність, потім структура коду. І кожне виправлення супроводжувати тестом, щоб не зламати суміжне. Якщо проєкт критичний для бізнесу, корисно підключити автоматичні перевірки: докладніше в статті про ручне та автоматизоване тестування.

Як відрізнити якісний аудит від формального

Ринок аудитів неоднорідний: від автоматичного звіту статичного аналізатора до глибокого розбору архітектури. Кілька ознак, що допоможуть оцінити пропозицію.

• Ручна перевірка, а не лише інструменти. Статичні аналізатори (PHPStan, Larastan) і composer audit корисні, але вони не бачать бізнес-логіки. Якщо весь аудит — це роздрукований вивід інструментів, ви платите за те, що могли запустити самі.
• Знахідки з прикладами. Кожне зауваження має файл, рядок і пояснення наслідків. «Рекомендуємо покращити безпеку» — не знахідка.
• Оцінка трудозатрат. План виправлень без орієнтовних годин не допоможе запланувати бюджет.
• Розмова з вами, а не лише з кодом. Аудитор має запитати, що для бізнесу найважливіше: швидкість каталогу, надійність оплати чи простота змін. Від цього залежать пріоритети.
• Чесні межі. Хороший аудитор прямо каже, що не перевірялося: наприклад, навантажувальне тестування чи юридична відповідність обробки персональних даних.

Якщо аудит пропонують безкоштовно «в подарунок» до розробки, пам'ятайте про конфлікт інтересів: той, хто пише код, рідко об'єктивно оцінює власну роботу.

Підсумок

Технічний аудит коду — не про те, щоб «знайти винних». Це спосіб замінити відчуття «щось не так» на конкретний перелік проблем, ризиків і дій. Він потрібен, коли проєкт змінює власника чи команду, повільніє, дорожчає в розвитку або готується до зростання. Результат — звіт, який можна передати будь-якій команді й виконати поетапно.

Хочете зрозуміти реальний стан вашого проєкту? Залиште бриф або напишіть нам на сторінці контактів: подивимося на проєкт і скажемо, чи потрібен повний аудит, чи вистачить консультації.