Блог

Як провести Code Review, щоб не образити колегу. Баланс позитивних і негативних коментарів

Code Review — обов’язковий етап супроводу IT-початківця. Цей процес має допомогти джуну виявити помилки та задати певний напрям розвитку. За найгірших умов код рев’ю може й демотивувати новачка. Як уникнути цього? Поділюсь власним досвідом і порадами.

У попередній частині ми поговорили про важливість код рев’ю та його основні етапи. Переходимо до реакції на коментарі.

Якщо після код рев’ю я бачу, що залишив багато негативних коментів, пропоную розробнику голосом обговорити результати роботи. У живій розмові легко донести думку: «У тебе багато помилок, але ми всі їх робили! Це не страшно. Все можна виправити». Порадьте джуну почитати відповідну документацію, щоб легше осягнути зауваження та внести правки. Інакше він може подумати, що ні на що не здатен. Початківця варто підтримувати. Адже він як мінімум впорався із задачею та передав код на рев’ю. А дехто і до цього етапу не доходить.

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

Мені подобається, коли код новачка наближений до мого кодстайлу. Якщо логіка подібна до твоєї, це спрощує розуміння проєкту. Інколи навіть дивлюсь на чужий код і думаю: ніби я написав! У таких випадках хочеться залишити позитивні коментарі, підбадьорити колегу.

Якщо певний фрагмент коду отримав апрув, то це вже позитивна оцінка. Тут немає помилок чи зауважень. Усе зроблено коректно, нічого переробляти не треба. Може, виглядає це сухо і стримано, але не варто і перехвалювати людину. Намагайтесь балансувати між зауваженнями і дійсно потрібними позитивними коментами.

Внесення пропозицій у пул реквестах та обговорення правок

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

У складних ситуаціях потрібен розгорнутий коментар. Найчастіше потреба виникає під час рев’ю коду не новачка, а фахівця зі схожою експертизою, коли в кожного своя точка зору. Тоді виправлення буде замало. Потрібні аргументи, приклади, конкретні пропозиції щодо реалізації певного моменту. Це ефективний підхід до вирішення проблеми, що дасть змогу швидше владнати спірне питання.

Хоча дискусія може затягнутися. Колега може так само аргументовано захищати свою ідею. Ви починаєте обговорення, пропонуєте рішення, пояснюєте його переваги й недоліки. Бесіда триває допоки хтось не погодиться з думкою іншого. У мене була ситуація, коли розробник наводив сильні, цікаві аргументи. Врешті я з погодився, але запропонував подумати над наслідками впровадження цього рішення на реальних кейсах. Так я показав: питання ще невирішене, є лише один зі шляхів. Тож в не варто виключати в майбутньому проблеми.

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

Ви можете потрапити на проєкт, в якому спеціаліст, чий код ви перевіряли, працює багато років. І тут є висока вірогідність того, що навіть коректні аргументи у ваших правках не будуть адекватно ним сприйняті. Він може проігнорувати зауваження. У випадку джунів з роком досвіду на цьому єдиному проєкті така реакція виглядає дивною. Особливо, якщо він не прислухатися до мідла з досвідом 3-4 роки на різних проєктах. Людина сприймає себе «хазяїном» проєкту, а вас — як чужинця, який диктує свої правила. Однак кодстайл молодого спеціаліста може бути нелогічним, помилковим і складним для підтримки проєкту в подальшому. Гадаю, єдиний вихід — звернутися, так би мовити, до рефері. На проєкті ним може виступити менеджер або лід. Хоча це вже не стільки про код рев’ю, скільки про взаємодію в команді.

Чи потрібно адаптувати код рев’ю до конкретної людини?

Мій підхід завжди залежить від людини та її характеру. Однозначно потрібен досвід роботи з конкретним фахівцем, вміння сприймати і розуміти його реакції на критику. Якщо я знаю, що початківець швидко проходить пул реквест і робить коректні висновки, то можу витрачати менше часу на аргументи. Бо ця людина довіряє мені і працює над собою. Можна написати «Виправ тут це» або «Ось тут краще зробити в такий-то спосіб». Тут я знаю: джуніор самостійно розбереться, чому я порадив зробити саме це, виправить і запам’ятає це рішення. Якщо ж він повторює помилки чи пропускає щось через неуважність, мені доводиться перевіряти буквально кожну букву. Через це код рев’ю буде йти іншим чином, а пул реквести оформлюватись інакше.

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

Негативне ставлення до код рев’ю — як реагувати ментору?

Зазвичай одразу помітно, як людина сприйняла ваші зауваження. Це не образа, але все одно певна форма негативу. Навіть якщо початківець погодився та виправив все, як-то кажуть, на душі гіркувато. Тож я раджу звертати увагу на поведінку та настрій людини після обговорення код рев’ю. Наприклад, на найближчому мітингу. Якщо побачите напруженість, краще зверніться до колеги й обговоріть усе ще раз. Скажімо, чому ви залишили так багато коментарів, чому вони стосувались тих чи інших моментів, чому на цьому ви так акцентуєте увагу. Тут важливо показати, що ви поважаєте фахівця і бажаєте йому добра. Як показує мій досвід, шанс зняти негатив у такій розмові досить високий.

Одного разу мене попросили провести код рев’ю новачка на іншому проєкті. Раніше цю людину менторив сеньор, який наводив йому певні аргументи. Джун їх завжди наслідував, притримувався заданих правил. А тому на багато моїх зауважень казав щось на кшталт «А мені сеньор говорив робити так!». Доводилось перепитувати: «Чому він це казав?». Виявлялось, нічого поганого в тих рішеннях немає, здебільшого то була суб’єктивна думка ментора. Ми спробували інші варіанти реалізації, і людина побачила різноманіття рішень. Йому сподобалося так працювати, і далі все пройшло спокійно.

Часто досвідчені, занурені у кілька проєктів експерти не готові довго пояснювати щось новачкам під час код рев’ю. Вони кажуть: «Тут погано, йди розбирайся, мені треба, аби все було нормально». Звісно, обтяжена різними задачами людина втомлюється від великих обсягів роботи. Тому може не приділяти достатньо часу на обговорення помилок свого підопічного. Але для останнього це має негативний вплив. По-перше, так джун буде повільно розвиватися. По-друге, у нього складається хибна думка, що саме так і проходить код рев’ю. Тому фахівець і в своїй практиці потім буде наслідувати подібну модель спілкування. В результаті він не буде якісно проводити код рев’ю та ефективно взаємодіяти з колегами.

Філософія ставлення до код рев’ю проста: пам’ятайте, що помилки трапляються у всіх. Колись я сприймав певні рішення у коді як найкращі, але згодом приходив до інших висновків і розумів, що був неправий. Я навіть не розумію, чому під час давніх код рев’ю наводив ті чи інші аргументи. Та все це приходить із досвідом.

Будьте уважні до думок інших, поважайте роботу колег і намагайтесь разом знаходити оптимальні рішення.