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

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

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

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

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

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

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

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

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

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

// До: функція робить усе одразу і мовчки ковтає помилки
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 [];
  }
}
// Після: назви пояснюють намір, помилки не зникають, типи чесні
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-співбесіди.

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

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

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

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

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

Такий чекліст – це, по суті, тренування навички self-review, яку перевіряють у сильних командах і яка помітно виділяє кандидата на технічній співбесіді.

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

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

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

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

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

Підсумок

Рев'ю коду – найшвидша петля зворотного зв'язку в навчанні програмуванню: воно працює з твоїм кодом, а не з абстрактними прикладами. Якщо в твоєму навчанні цієї петлі немає взагалі – саме її варто додати першою, у будь-якому форматі: колега, спільнота або ментор. Як оцінити, чи дасть конкретний ментор якісне рев'ю, – окремий розбір у статті як обрати IT-ментора.