Код-ревʼю

Погляд каналу — з перших рук: Віктор спирається на практику ревʼю і у WebbyLab, і в Google та наполягає, що єдиного правильного способу не існує — але є прийоми, які роблять кращим будь-яке ревʼю (як код-ревʼю робить Google). Стандартизуйте гайдлайни (коли обидва підходи однаково прийнятні — просто оберіть один, щоб на ревʼю перестали пересперечуватися про смак) і повністю автоматизуйте стиль, щоб час сеньйорів ніколи не витрачався на коментарі про форматування. Систему Google він описує зсередини: пір-ревʼю, де джуніор може ревʼюїти сеньйора, плюс окрема сертифікація «readability» для кожної мови (~6 місяців на TypeScript, роки на C++) — код не може змерджитися без апруву власника readability, тож у його команді джуніор з readability апрувив його код, тоді як його власного апруву було недостатньо. Сторона автора важить не менше: один концерн на MR, справжні описи, скриншоти і скрінкасти «до/після» — зробіть ревʼю максимально легким для ревʼюера.

Найгостріша його теза — що самого лише ревʼю на рівні PR ніколи не досить: кожен дифф може виглядати чудово, поки архітектура тихо перестає працювати, — саме тому Google додатково проводить post-launch-ревʼю, де автор фічі проводить команду по вже змердженому коду, а WebbyLab — періодичні архітектурні ревʼю (див. технічний борг і проєктування ПЗ). В епоху AI практика поширюється і на машинний код: написаний AI код треба читати рядок за рядком, як людський PR, — він дивиться, як правки Claude стрімляться в терміналі, і тисне Escape, щойно щось іде не так, або ревʼюїть повний дифф для великих one-shot змін — і зауважує, що AI вже ревʼюїть більше PR-ів, ніж пише, а решту все одно ревʼюїть людина (вайб-кодинг, частина 2).