У всіх командах, з якими я колись працювала, код-рев’ю було обов’язковим. Але зовсім не завжди від нього була користь. Траплялось таке, що рев’ю перетворювалось на банальну втрату часу, а інколи взагалі переходило в повноцінне джерело стресу для окремих людей і блокінг для роботи команди загалом.
Чому так? Через погану організацію та відсутність розуміння, яка взагалі кінцева мета цього дійства.
Нижче розглянемо кілька ознак, які можуть свідчити про те, що над процесом код-рев’ю в вашій команді треба ще подумати.
Увага тільки на технічний аспект
Рев’ю - це не тільки про якість коду. Це важлива частина, яку не слід ігнорувати, але не найважливіша. Найважливіша частина - упевнитись, що код, який ви дивитесь, буде відповідати бізнес-вимогам. Як це?! - спитаєте ви, - Чого це Я маю ЦИМ займатись?
Ну по-перше, ніхто не казав, що рев’ю - це просто. Це складно. І вимагає відповідальності. Тому якщо вже взялись робити, то робіть нормально.
А по-друге, кінцева мета деліверінгу кожної фічи - це вдовольнити потреби замовника, чи не так? Замовнику, як правило, нема діла до того, який патерн ви вирішили використати, а от до того, чи правильно ви заімплементили edge-кейси - ще й яке діло є!
Найпростіший спосіб перевірити, чи правильно ваш колега розуміє бізнес-вимоги - це подивитись юніт-тести. По-перше, вони присутні? Вони охоплюють граничні випадки? Чи відповідають вони взагалі загальному розумінню фічі?
Аналізуючи юніт-тести, легко зрозуміти, чи людина врахувала всі можливі результати роботи свого коду.
Звичайно, ви зараз подумали про те, що займатись цим на рев’ю необов’язвково, адже є QA, це їх робота, хай перевіряють, що там по edge-кейсам. Частково ви праві. Але будь-яка дев команда має репутацію. Чи влаштовує вас репутація команди, яка неякісно робить свою роботу?
Відсутність відповідальності
Рев’ю, як правило, це частина ваших обов’язків. І ваша задача виконувати ці обов’язки належним чином, що означає, що поверхнево пройтись по ПР - недостатньо. З моменту, коли ви натискаєте кнопку "Approve", ви стаєте так само відповідальними за цей код, як той, хто його написав.
Тому ви повинні вкласти достатньо часу в цей процес або взагалі відмовитись від нього.
Не робіть роботу наполовину.
Використання "Мені це не подобається" як аргументу
Є багато способів зробити одну й ту ж річ - більше, ніж один. І, може статися так, що інша людина вибере інший спосіб. Тут немає жодної трагедії. І не потрібно розпочинати холівар через використання певного підходу або відсутність патерну. Код легко читається? Робить те, що треба? Тоді все в порядку. Чи зробили б ви це інакше? Це не має значення.
Ігнорування обмежень часу
Ми завжди хочемо робити речі краще. Але ви повинні думати про пріоритети. Тому, коли ви робите код-рев’ю, завжди зважайте на поточну ситуацію в проекті. Якщо є достатньо часу, є достатньо місця для вдосконалення. Але якщо кінець спрінта сьогодні, а вам конче захотілось попросити колегу переписати ооооцей кусочок коду (бо так буде краще!1!), то я пропоную відкласти рефакторинг на наступний спрінт.
Хамство
Пам'ятайте, ви перевіряєте результат, інколи багатоденної, роботи іншої людини. Навіть якщо є помилки або код відверто поганий, це все одно ваш колега. Він заслуговує на базову повагу.
Моє правило - залишати коментарі у формі питання.
"Можливо, краще зробити це іншим шляхом?" звучить набагато краще, ніж "Боже, ні, а-ну перероби!".
Все ж таки, ви хочете підтримувати гарні стосунки з командою.
TL;DR
Під час рев’ю перевіряйте як технічне втілення, так і відповідність коду вимогам. Будьте уважними, оскільки ви несете відповідальність за це. Не витрачайте час на сперечання про найкращі практики - думок більше, ніж одна. Враховуйте поточний стан проекту і пропонуйте масштабні зміни лише в разі наявності часу для їх виконання. І, звичайно, завжди будьте ввічливими.
Дякую, що дочитали :) Пишіть ваші думки в коментарях!
