Модуль 9 · урок 6 з 9

Code review

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

Як читати чужий PR

Прочитай опис і задачу. Без контексту рев'ю перетворюється на причіпки до стилю.
Пройди дифом згори вниз, не коментуючи. Спершу зрозумій ціле.
Другим проходом залишай коментарі. Тепер видно, що справді важливо.
Перевір найризикованіше: обробку помилок, межі, стани завантаження й порожнечі.
Запусти локально, якщо зміни в інтерфейсі. Скріншот в описі не показує поведінки.

Що шукати передусім

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

Як писати коментарі

Працює

«Тут можна впасти, якщо assigneeId буде null — може, додати ?.?»
«Здається, цей subscribe не відписується. Або я щось пропустив?»
«Не критично, але computed тут читався б простіше.»
«Питання: чому саме switchMap, а не concatMap? Це збереження.»

Псує стосунки

«Це неправильно.»
«Хто так пише?»
«Перепиши все.»
«Дивись документацію.»
Двадцять коментарів про пробіли.

Різниця в двох речах: питання замість вироку й причина замість оцінки. «Тут можна впасти, якщо…» — це факт із поясненням, на нього легко відповісти. «Це неправильно» — це присуд, на який хочеться захищатись.

Позначай важливість

🔴 Блокує: тут витік підписки, після десяти відкриттів екрана буде помітно.
🟡 Варто виправити: назва `data` нічого не каже — може, `visibleTasks`?
🟢 На майбутнє: цей мапер можна винести, але не в цьому PR.
💭 Просто питання: чому обрано саме такий поріг?

Без позначок автор не розуміє, що з двадцяти коментарів обовʼязкове, а що побажання. Через це або виправляють усе (довго), або нічого (небезпечно). Чотири рівні знімають цю невизначеність повністю.

Як приймати критику

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

Найкорисніша фраза на рев'ю

«Не зрозумів цей шматок — поясниш?» Вона працює в обидва боки. Як рев'ювер ти не мусиш вдавати, що все зрозумів. Як автор ти отримуєш сигнал, що код потребує коментаря або спрощення: якщо колега не зрозумів зараз, ти сам не зрозумієш через рік.

Рев'ю самому собі

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

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

≈ 35 хв · +25 XP за урок