Навіщо code review

Можливо, я один такий, але мене дратують жарти типу

Ну, тобто сам жарт ок — i-know-that-feel.png, #relatable, усе таке. Але у ньому кілька прикладів поганої поведінки і авторів коду, і ревʼюверів:

• поверхневі коментарі;
• величезні патчі;
• нестача контексту;
• читання «по діагоналі»

Тож якщо проблеми з code review настільки поширені, то на них треба не лише показувати пальцем, але і якось виправляти. Зробити це можна або зовнішними вимогами/обмеженнями, або внутрішньою мотивацією

Вимагати «будь краще» — глупо. Автоматично відсікати code review через метрики — не варіант, тому що «зрозумілість» не виміряти скріптом. Тому «покращити code review зовнішніми вимогами/обмеженнями» відпадає

Вплинути на внутрішню мотивацію можна особистим прикладом, але після років спроб, це здається занадто повільним і не те щоб надійним. Можливо, особистий приклад буде швидше донести словами

Серія записів про code review:

1. Навіщо?
2. Створення pull request’у
3. Думки про pull request assignee
4. Code review & response

Англійською: On Code Reviews

Час та місце

Я працював лише у доволі зрілих продуктових компаніях. Коли компанія роками працює над продуктом, внесок часу та зусиль у code review виправдано не лише через «ну, це правильно», але і через спрощення підтримки у довгому строку

Зовсім молоді продукти, для яких того самого довгого строку може ніколи і не бути, ризикують тим, що після усіх review залишиться лише «правильний», але нікому не потрібний код

Як виглядають справи з клієнтською роботою (агенції/аутсорс/аутстаф) я не знаю. З одного боку, якщо клієнт повернеться за доопрацюванням через рік-другий, минулі code review допоможуть швидше згадати/впізнати кодову базу. З іншого — клієнт може ніколи не повернутися

Тож code review може бути зовсім марним (або взагалі шкідливим) на твоєму місці роботи. Або він був таким на минулому місці роботи твоєї нової колеги…

Мотивація

Окей, припустимо ти працюєш у відповідній команді, у відповідний час, і тобі дуже хочеться краще писати та коментувати pull request’и. Щоб знати напрямок для покращень, треба розуміти, яка мета code review

Тож, навіщо проводити code review?

Мені сказали, що тут так прийнято

«Так історично склалося» — поганий шлях до покращень. Він приведе туди ж, звідки він почався. Навіть нема буде про що розповісти (якщо тобі не подобаються історії, в яких нічого не відбувається)

Щоб ідіоти нічого не поламали у моєму ідеальному проєкті

Ці «ідіоти» відкрили PR тому що їм треба щось виправити або щось покращити. Якщо твій ідеальний проєкт не тримається на плаву лише завдяки твоєму gatekeeping’у, то краще спрямуй зусилля в написання тестів і налаштування лінтеру

Щоб зловити те, що важко або взагалі неможливо покрити тестами

Тепліше… Але «володарям знань» швидко набридне вдивлятися сотні та тисячі рядків коду у пошуках одних і тих самих проблем, з якими стикаються колеги, незнайомі з репозиторієм

З «зробити собі побільше рутини» виходить погана мета. Хотілося б, щоб воно саме

Але новачки репозиторію (саме репозиторію — в них може бути величезний досвід розробки взагалі) не знають, що {placeholder}створить проблеми. А досвідчені вже настільки часто стикалися з {placeholder}, що інстинктивно його уникають

Тому, щоб воно саме, автори та ревʼювери мають обмінюватися особистим розумінням проєкту:

• автори явно та неявно вказують на дивину у існуючому коді. Наприклад, що для досягнення простої мети треба зробити купу ручної роботи
• ревʼювери діляться базовими припущеннями, на яких працює проєкт, на кшталт «на помилки ми повертаємо код 200 и обʼєкт с ключем error через рішення, яке було прийняте десять років тому и навколо якого написано багато коду»

Іншими словами, you need two to tango have a good code review

Продовження: Створення pull request’у