Пошук уроків, статей та іншого контенту
Проводьте конструктивний code review, перевіряючи коректність, підтримуваність, безпеку й відповідність вимогам.
Code review — це перевірка змін у коді іншими розробниками перед їх об’єднанням з основною гілкою.
У Git code review зазвичай відбувається навколо:
окремої feature-гілки;
набору комітів;
pull request або merge request;
порівняння змін з цільовою гілкою, найчастіше main.
Мета review — не лише знайти помилки. Під час перевірки потрібно з’ясувати, чи:
реалізація відповідає вимогам;
код працює для очікуваних і граничних випадків;
зміни не ламають наявну функціональність;
код залишається зрозумілим і підтримуваним;
не з’явилися вразливості або витік конфіденційних даних;
зміни можна безпечно об’єднати з цільовою гілкою.
Code review — це перевірка коду, а не оцінювання людини, яка його написала.
Якісний review починається з якісно підготовленої гілки.
Перед створенням pull request варто:
Переконатися, що зміни стосуються однієї задачі.
Запустити тести та інші перевірки проєкту.
Перевірити власні зміни через git diff
Видалити випадкові файли, логи та тимчасовий код.
Написати зрозумілий опис змін.
Вказати відомі обмеження або питання, які потребують обговорення.
# Показати зміни між поточною гілкою та спільним предком з main
git diff origin/main...HEAD
# Перевірити пробіли наприкінці рядків та інші очевидні помилки у diff
git diff --check
# Показати список змінених файлів
git diff --stat origin/main...HEAD
# Переглянути історію комітів поточної гілки
git log --oneline --decorate origin/main..HEADТри крапки в git diff origin/main...HEAD означають порівняння HEAD зі спільним предком двох гілок. Це зазвичай відповідає тому, що потрібно переглянути в pull request.
Чим більший diff, тим складніше його надійно перевірити. Якщо зміни охоплюють кілька незалежних задач, їх краще розділити на окремі pull request.
Невеликий і сфокусований pull request:
швидше перевірити;
простіше обговорити;
легше відкотити;
має менший ризик приховати помилку серед несуттєвих змін.
Корисно перевіряти зміни у кілька проходів.
Спочатку прочитайте опис задачі та pull request:
Яку проблему вирішують зміни?
Яка очікувана поведінка?
Які частини системи повинні змінитися?
Чи є обмеження щодо продуктивності, сумісності або безпеки?
Як перевірити результат?
Не варто одразу аналізувати кожен рядок, не розуміючи мети змін.
Перегляньте список файлів і комітів:
# Отримати актуальні дані з віддаленого репозиторію
git fetch origin
# Переглянути змінені файли
git diff --name-status origin/main...feature/payment-validation
# Переглянути коміти, яких немає у main
git log --oneline origin/main..feature/payment-validationНа цьому етапі перевірте:
чи всі змінені файли пов’язані із задачею;
чи не змінено надто багато компонентів без пояснення;
чи немає випадково доданих файлів;
чи логічно поділені коміти;
чи не містить гілка незавершених змін.
Далі потрібно перевірити поведінку коду.
Звертайте увагу на:
основний сценарій;
порожні значення;
неправильний тип або формат даних;
мінімальні та максимальні значення;
повторні виклики;
помилки зовнішніх сервісів;
частково виконані операції;
сумісність зі старими даними.
Наприклад, якщо зміна додає перевірку суми платежу, недостатньо перевірити лише позитивне число. Потрібно подумати про:
0;
від’ємні значення;
дуже великі числа;
null або відсутнє поле;
значення у вигляді рядка;
округлення десяткових чисел.
Якщо поведінка неочевидна, попросіть додати тест або уточнити вимогу.
Підтримуваний код не обов’язково має бути найкоротшим. Важливіше, щоб його можна було безпечно змінювати надалі.
Перевірте:
чи зрозумілі назви змінних, функцій і класів;
чи відповідає структура коду його відповідальностям;
чи не дублюється складна логіка;
чи не змішані різні рівні абстракції;
чи не створено зайву складність;
чи відповідає код стилю проєкту;
чи достатньо тестів для важливої логіки.
Під час review розрізняйте обов’язкові проблеми та особисті вподобання. Якщо стиль уже визначено правилами проєкту, посилайтеся на ці правила. Якщо це лише альтернативний варіант, краще сформулювати коментар як запитання або рекомендацію.
Безпеку потрібно перевіряти не лише у спеціальних security-related задачах.
Зверніть увагу на:
секрети, токени й паролі в коді або конфігурації;
значення з користувацького введення;
формування SQL-запитів, команд або HTML;
недостатню перевірку прав доступу;
розкриття зайвих даних у відповідях і логах;
небезпечне зберігання персональних даних;
обхід перевірки на клієнтській стороні без серверної перевірки;
завантаження файлів і перевірку їх типу та розміру.
Секрет, випадково доданий у Git, не стає безпечним після видалення з останнього коміту. Якщо він уже потрапив у віддалений репозиторій, його потрібно вважати розкритим і замінити.
Код може бути технічно правильним, але не відповідати задачі.
Порівняйте реалізацію з критеріями приймання:
чи реалізовані всі обов’язкові сценарії;
чи правильні тексти помилок;
чи збережено необхідну сумісність;
чи правильно обробляються права доступу;
чи відповідає формат відповіді очікуванням;
чи не додано поведінку, якої не вимагала задача.
Корисно перетворити опис задачі на список перевірок і пройти його пункт за пунктом.
Diff потрібно читати не лише построчно, а й у контексті всієї функції або модуля.
-const limit = user.plan === "pro" ? 100 : 10;
+const limit = user.plan === "pro" ? 1000 : 10;
const items = await loadItems(user.id);
return items.slice(0, limit);Під час перевірки такого фрагмента можна поставити запитання:
Чи справді для плану pro потрібен ліміт 1000?
Що відбувається для невідомого або відсутнього плану?
Чи може loadItems повернути більше даних, ніж безпечно обробити система?
Чи оновлені тести?
Чи не потрібно змінити документацію або конфігурацію?
Корисні команди:
# Показати конкретний коміт разом із diff
git show --stat --oneline <commit>
# Показати зміни конкретного коміту
git show <commit>
# Показати diff лише для одного файлу
git diff origin/main...HEAD -- src/services/items.js
# Переглянути зміни без кольорового форматування, наприклад для скриптів
git -c color.ui=false diff origin/main...HEADЩоб автору було зрозуміло, що потрібно виправити до об’єднання, позначайте важливість коментарів.
Можна використовувати такі категорії:
Blocker — критична проблема: вразливість, втрата даних, помилкова бізнес-логіка або гарантований збій.
Major — суттєва проблема, яка впливає на функціональність або підтримуваність і має бути виправлена.
Minor — невелике покращення, яке бажано зробити, але воно не блокує об’єднання.
Question — запит на пояснення або уточнення.
Nit — незначна стилістична пропозиція, яка не повинна блокувати review.
Якщо команда не використовує формальні позначки, ті самі відмінності можна передавати словами: «потрібно виправити», «рекомендую», «не блокує об’єднання».
Хороший коментар містить:
конкретне місце проблеми;
пояснення ризику або причини;
можливий напрям вирішення;
за потреби — питання замість категоричного твердження.
Невдалий коментар:
Це погано написано.
Конструктивніший варіант:
Ця перевірка виконується лише на клієнті, тому її можна обійти прямим HTTP-запитом. Чи можемо повторити перевірку прав на сервері перед виконанням операції?
Ще один приклад:
Тут функція одночасно завантажує дані, перетворює їх і формує відповідь. Через це її складно тестувати частинами. Чи варто винести перетворення в окрему функцію?
Формулюйте коментарі про код, а не про особисті якості автора:
«Цей сценарій не обробляється» замість «Ти забув обробити сценарій».
«Назва не відображає фактичну поведінку функції» замість «Назва погана».
«Це може призвести до витоку токена в логах» замість «Не логуй такі речі».
Запитання корисне, коли ви не впевнені в контексті:
Чи може
accountбути відсутнім для цього endpoint? Якщо так, викликaccount.idзавершиться помилкою.
Такий формат заохочує автора пояснити припущення або додати обробку граничного випадку.
Не перетворюйте кожен коментар на запитання, якщо проблема очевидна й критична. Вразливість або гарантований збій потрібно описати прямо.
Автоматичні інструменти можуть перевірити:
форматування;
синтаксис;
типи;
тести;
статичний аналіз;
відомі проблеми залежностей;
базові security-правила.
Але автоматизація не визначає повністю:
чи правильно зрозуміли вимогу;
чи зручна поведінка для користувача;
чи добре обрана архітектура;
чи не пропущений бізнес-сценарій;
чи достатній рівень доступу;
чи зрозуміла назва для майбутнього розробника.
Тому успішне проходження CI не означає, що review завершено.
Перед схваленням змін корисно виконати щонайменше:
# Переконатися, що робоче дерево не містить неврахованих змін
git status --short
# Перевірити помилки форматування diff
git diff --check
# Запустити тести проєкту
npm test
# Перевірити повний diff гілки
git diff origin/main...HEADКоманди тестування залежать від проєкту. Не потрібно запускати npm test, якщо проєкт використовує іншу систему збірки або інший менеджер пакетів.
Після виправлень автор може додати нові коміти. Reviewer повинен перевірити не лише останній коміт, а й результат усієї гілки.
# Оновити посилання на віддалені гілки
git fetch origin
# Переглянути всі актуальні зміни feature-гілки
git diff origin/main...feature/payment-validation
# Переглянути останні коміти гілки
git log --oneline origin/main..feature/payment-validationПісля кожного виправлення перевірте:
чи справді проблема зникла;
чи не з’явилися побічні ефекти;
чи не було змінено зайвий код;
чи додано або оновлено тест;
чи не виникли конфлікти з актуальним main.
Якщо pull request оновився суттєво, повторіть review з початку, а не обмежуйтеся переглядом кількох нових рядків.
Нехай розробник створив гілку feature/order-limit:
# Перейти на основну гілку та отримати її актуальний стан
git switch main
git pull --ff-only origin main
# Створити гілку для задачі
git switch -c feature/order-limit
# Після внесення змін перевірити їх локально
git diff --check
npm test
# Переглянути зміни перед публікацією
git diff main...HEAD
# Зафіксувати підготовлені зміни
git add src tests
git commit -m "Add order limit validation"
# Опублікувати гілку
git push -u origin feature/order-limitReviewer після цього:
читає опис задачі;
переглядає список змінених файлів;
аналізує diff;
запускає тести або перевіряє результати CI;
перевіряє вимоги, коректність, підтримуваність і безпеку;
залишає конкретні коментарі;
після виправлень перевіряє актуальний diff;
схвалює зміни або вказує, що саме ще потрібно виправити.
Останній коміт може містити тільки виправлення, а основна проблема — у попередньому коміті.
Замість цього переглядайте весь набір змін:
git diff origin/main...HEADФорматування важливе, але воно не замінює перевірку поведінки, вимог і безпеки.
Якщо тестове оточення доступне, перевірте результати CI або запустіть потрібні команди локально.
Коментарі про пробіли або стиль не повинні приховувати помилки в бізнес-логіці чи вразливості.
Review має стосуватися поточної задачі. Не варто блокувати зміни через повний рефакторинг коду, якщо він не потрібен для виправлення конкретної проблеми.
Коментарі на кшталт «ти не розумієш» або «нормальний розробник так не пише» не допомагають виправити код і руйнують співпрацю.
Фраза «перероби» не дає автору достатньо інформації. Пояснюйте, яка поведінка неправильна та чому вона важлива.
Якщо частина реалізації зроблена добре, це також варто зазначити. Позитивний конкретний відгук допомагає закріпити корисні практики.
Code review у Git перевіряє зміни feature-гілки перед їх об’єднанням з основною гілкою.
Починайте з контексту задачі та загальної структури diff, а потім переходьте до окремих рядків.
Перевіряйте коректність, граничні випадки, підтримуваність, безпеку й відповідність вимогам.
Використовуйте git diff, git diff --check, git show і git log для аналізу змін.
Розділяйте критичні проблеми, рекомендації та стилістичні зауваження.
Формулюйте коментарі конкретно, пояснюйте ризик і критикуйте код, а не автора.
Автоматичні тести й CI доповнюють ручний review, але не замінюють його.
Після виправлень потрібно перевіряти актуальний повний diff, а не лише нові коміти.