Опишіть процес code review. Назвіть основні правила, способи вирішення конфліктів і суперечок під час його проведення.

Повне пояснення

Що це і навіщо Code review — це колективна перевірка коду, що допомагає виявляти баги, покращувати читабельність і підтримувати консистентність проекту. Це також інструмент навчання та передачі знань між розробниками.

Ключові принципи

• Об’єктивність: оцінка базується на фактах, а не на особистих вподобаннях.
• Фокус на функціональності: перевірка, чи працює код так, як очікується.
• Безпека: виявлення потенційних вразливостей (SQL‑ін’єкція, XSS тощо).
• Читабельність: код має бути зрозумілим і підтримуваним.
• Документованість: коментарі, опис змін і причини прийняття рішень.

Як це працює

1. Підготовка: автор створює pull request (PR) і додає опис змін.
2. Ревізія: ревьюер читає код, коментує в PR, задає питання.
3. Обговорення: автор відповідає на коментарі, вносить зміни.
4. Затвердження: коли всі коментарі вирішені, PR мержиться.

Способи вирішення конфліктів

• Об’єктивні критерії: посилання на код‑стайл, тестові кейси або вимоги.
• Діалог: відкритий обмін думками, без критики особистості.
• Медіація: залучення senior‑розробника або технічного лідера, якщо суперечка не вирішується.
• Документування рішення: запис у PR, щоб уникнути повторних конфліктів.

Практика й реалізація

• У GitHub/Bitbucket PR‑тема: «Add user authentication with JWT».
• Ревьюер додає коментарі: // TODO: validate email format.
• Автор змінює код, коментує // Fixed: added regex validation і закриває коментар.

Тестування

• Після merge CI запускає unit‑тести (Jest, Mocha) і linting.
• Якщо тест падає, ревьюер вказує на конкретний рядок.

Оптимізація процесу

• Checklists: список критеріїв (наприклад, security, performance).
• Timeboxing: обмежити час на review (наприклад, 1–2 години).
• Automated reviews: статичний аналіз (ESLint, SonarQube) допомагає виявити прості помилки.

Безпека

• Перевірка на SQL‑ін’єкцію, XSS, CSRF.
• Використання параметризованих запитів або ORM‑методів.

Особливості в контексті DevOps

• CI/CD pipeline автоматично перевіряє PR перед merge.
• Якщо конфлікт з мерджем, CI сигналізує про необхідність вирішення.

Часті помилки

1. Перегляд коду без тестів → баги залишаються.
2. Суб’єктивні коментарі → конфлікти.
3. Відсутність документації → непорозуміння.
4. Необхідність повторного merge після зміни PR → затримка релізу.
5. Перевантаження ревьюера → низька якість review.
6. Відсутність чітких критеріїв → різні інтерпретації.
7. Необхідність ручного мерджу → ризик конфліктів.
8. Відсутність автоматичних тестів → збільшення дефектів у продакшн.

Cheatsheet

• Review checklist: functionality, security, performance, readability.
• Conflict resolution: use git merge --no-ff, discuss in PR, document decision.
• Follow‑up questions: "Як ви перевірили безпеку цього endpoint?", "Чи є тест, що охоплює цей кейс?".