Чим відрізняється новачок і ментор в IT? Перший — пише код, другий — ревʼювить. І якщо для ментора Code Review — звична справа, то у джуна все може бути не так однозначно. Бо коментарі досвідчених девелоперів можуть як спонукати початківців до розвитку, так і демотивувати їх. Все залежить від ментора й обраного підходу. 

Євген Бодня, Angular Developer у команді NIX, вже довгий час допомагає новачкам покращувати свій код через рев’ю і ділиться набутим досвідом. Тож, користуйтеся порадами і менторте відповідально. 

Поясніть навіщо

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

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

А ще Code Review дозволяє досягти оптимальної читабельності коду. Чистий код спрощує його подальшу підтримку як на вашому боці, так і на стороні замовника. Адже відповідно до життєвого циклу проєкту, він може перейти до іншої команди. І тоді вже інші девелопери будуть розбиратися з вашим кодом, додавати нові фічі чи розв’язувати знайдені проблеми.

Окресліть очікування

Щоби рев’ю не демотивувало джуна, зазначте повний перелік вимог до коду. Так ви не лише попередите можливість деструктивної комунікації, а й спростите собі життя. Джун може занотувати собі вимоги й тренуватися перевіряти власний код. 

Отже, наведемо неповний перелік вимог до кодингу: 

• дотримання стандартів кодування;
• уважність до деталей (відсутність зайвих рядків та пробілів, кожен рядок закриває крапка з комою);
• відсутність орфографічних помилок (назви функцій, змінних або класів написані англійською правильно);
• оптимізація коду;
• правильне використання бібліотек і фреймворків;
• точність даних в системі контролю версій. Наприклад, розробник може ненавмисно викликати певну команду в терміналі, що загрожує випадковим видаленнмя даних або надсилання їх до репозиторію на сервері. Новачки також часто роблять помилки під час маніпулювання гілками в Git, особливо після код рев’ю. Це може призводити до невідображення змін в програмі, виникнення конфліктів та неробочого коду. Іноді помилки можуть бути непомітними, і система може повернутись до попереднього стану, залишаючи конфлікти непоміченими. Щоб виявити такі проблеми, необхідно проводити ручне тестування коду.

Відділяйте критичні примітки від рекомендацій

Під час Code Review треба розрізняти дійсно необхідні та просто бажані коментарі. Передусім зосереджуюсь на невідкладних виправленнях. Якщо бачу певні рішення в коді, які можна було б зробити інакше, залишаю пораду: “Це краще реалізувати інакше, але те, що зроблено, не критично”. 

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

Code Review ≠ лише коментарі в пул реквесті

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

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