# Як проходить code review з ментором: процес, типові зауваження і користь

> Чим навчальне code review відрізняється від рев’ю в команді, як виглядає процес від PR до рефакторингу, типові категорії зауважень у коді початківців і чекліст самоперевірки.

- Автор: Юра Скиба (https://cookiesoftware.io)
- Опубліковано: 2026-09-24
- Категорія: Співбесіди та кар’єра
- Canonical: https://cookiesoftware.io/blog/code-review-z-mentorom

---

**Коротка відповідь.** Code review з ментором – це не пошук помилок заради помилок, а найшвидший спосіб дізнатися, чого ти не бачиш у власному коді. На відміну від рев'ю в команді, де мета – влити безпечний код у продукт, мета навчального рев'ю – щоб наступного разу ти сам написав краще. Процес простий: ти пушиш код у GitHub, отримуєш коментарі, розбираєш найважливіші на сесії і закріплюєш рефакторингом.

## Чим навчальне рев'ю відрізняється від рев'ю в команді

Якщо ти вже працюєш, у тебе може виникнути питання: навіщо окреме рев'ю, якщо його роблять колеги? Різниця у меті й глибині:

| | Рев'ю в команді | Рев'ю з ментором |
|---|---|---|
| Мета | Безпечно влити код у продукт | Твій ріст як інженера |
| Глибина | «Досить добре для мержа» | «Чому саме так і які були альтернативи» |
| Час рев'юера | Обмежений робочими пріоритетами | Заплановані сесії саме під це |
| Пояснення | Часто короткі: «поправ тут» | Розбір причини, патерна й наслідків |
| Безпека питань | «Незручно перепитувати вп'яте» | Питати – і є суть формату |

У команді нормально, що рев'ю поверхове: у людей свої дедлайни. Навчальне рев'ю існує саме для того, на що в команді немає часу.

## Як виглядає процес

1. **Ти пишеш код у своєму темпі** – навчальний проєкт, задача з плану або робочий пет-проєкт.
2. **Пуш у GitHub і Pull Request.** Побічний бонус: ти звикаєш до робочого флоу з гілками й PR ще до першої роботи.
3. **Письмові коментарі.** Не «переправ тут», а з поясненням: що не так, чому це проблема і в який бік думати.
4. **Розбір на сесії.** Найважливіші зауваження розбираються голосом із живим кодом: тут з'являється розуміння, а не механічне виправлення.
5. **Рефакторинг.** Ти переписуєш код сам – саме цей крок перетворює зауваження на навичку.

Цикл повторюється, і десь на третьому-четвертому колі відбувається головне: ти починаєш чути голос рев'юера ще під час написання коду.

## Типові категорії зауважень у коді початківців

Узагальнений досвід рев'ю Junior-коду зводиться до кількох категорій, що повторюються. Ось типовий приклад «до/після» (узагальнений, не з реальної роботи учня):

```ts
// До: функція робить усе одразу і мовчки ковтає помилки
async function getData(u: string) {
  try {
    const r = await fetch(u);
    const d = await r.json();
    return d.items.filter((x: any) => x.active == true);
  } catch (e) {
    return [];
  }
}
```

```ts
// Після: назви пояснюють намір, помилки не зникають, типи чесні
type Item = { id: string; active: boolean };

async function fetchActiveItems(url: string): Promise<Item[]> {
  const response = await fetch(url);
  if (!response.ok) {
    throw new Error(`Не вдалося завантажити items: ${response.status}`);
  }
  const data: { items: Item[] } = await response.json();
  return data.items.filter((item) => item.active);
}
```

Що тут відображено з типових категорій:

- **Naming.** `u`, `r`, `d`, `x` не кажуть нічого; `fetchActiveItems` і `response` читаються без коментарів.
- **Обробка помилок.** `catch → return []` ховає проблему: UI показує «порожньо» замість «сталася помилка», і дебажити це потім боляче. Помилка має бути видимою тому, хто викликає функцію.
- **Чесні типи.** `any` і `== true` – сигнали, що типова система вимкнена саме там, де вона найпотрібніша.
- **Одна відповідальність.** Завантаження і фільтрація в одній функції – дрібниця тут, але звичка, яка на більших задачах перетворюється на неможливість тестувати.

Інші часті категорії: дублювання логіки замість винесення у функцію, мутації там, де очікується новий об'єкт, і структура файлів «усе в одному компоненті». До речі, саме ці теми найчастіше спливають і на співбесідах – детальніше в [гайді підготовки до React-співбесіди](/blog/react-interview-guide).

## Як взяти з рев'ю максимум

- **Не виправляй мовчки.** Якщо не зрозумів, чому зауваження важливе, – спитай. «Виправив, бо сказали» не дає росту.
- **Шукай патерн, а не місце.** Отримав коментар про обробку помилок в одній функції – перевір усі інші сам.
- **Веди список своїх типових зауважень.** Через місяць це найчесніша карта твого прогресу: старі категорії зникають, з'являються глибші.
- **Проси рев'ю до того, як «усе готово».** Рання перевірка напряму дешевша за пізнє переписування.

## Чекліст самоперевірки перед тим, як показати код

Пройдися по ньому до рев'ю – і половина типових зауважень зникне:

1. Чи можу я пояснити кожну функцію одним реченням?
2. Чи кажуть назви змінних, ЩО в них лежить, без зазирання в код?
3. Що станеться при помилці мережі / порожніх даних / некоректному вводі?
4. Чи є шматок, який я скопіював двічі? Чому він ще не функція?
5. Чи є `any`, і якщо так – чи можу я чесно пояснити навіщо?
6. Чи запуститься проєкт у людини, яка бачить його вперше (README, команди)?

Такий чекліст – це, по суті, тренування навички self-review, яку перевіряють у сильних командах і яка помітно виділяє кандидата на [технічній співбесіді](/blog/pidhotovka-do-tekhnichnoi-spivbesidy).

## Часті питання про формат

**Який код підходить для рев'ю?** Будь-який, над яким ти реально працюєш: навчальний проєкт, пет-проєкт, тестове завдання. Головна вимога – код має бути твоїм: рев'ю чужого туторіального коду нічого не навчить.

**Як часто потрібне рев'ю?** Краще регулярно і невеликими порціями, ніж рідко і «весь проєкт одразу». PR на 200 рядків отримає глибокий розбір; PR на 2000 рядків – по діагоналі, і так у будь-якій команді світу.

**Чи має сенс рев'ю, якщо я вже Middle?** Так, але фокус зміщується: з naming і обробки помилок на архітектуру, межі модулів, тестову стратегію і компроміси. Питання «чому саме так, і що буде через пів року» на цьому рівні цінніші за пошук локальних недоліків.

**Що робити, якщо зауважень дуже багато і опускаються руки?** Це нормальний перший ефект. Попроси розставити пріоритети: 2–3 категорії, які варто виправити зараз, і решту – у бекліст. Ріст іде через патерни, а не через кількість закритих коментарів.

## Підсумок

Рев'ю коду – найшвидша петля зворотного зв'язку в навчанні програмуванню: воно працює з твоїм кодом, а не з абстрактними прикладами. Якщо в твоєму навчанні цієї петлі немає взагалі – саме її варто додати першою, у будь-якому форматі: колега, спільнота або ментор. Як оцінити, чи дасть конкретний ментор якісне рев'ю, – окремий розбір у статті [як обрати IT-ментора](/blog/yak-vybraty-it-mentora).