В інтернеті повно статей, в яких написано, що code review — надзвичайно гарна штука, яка підвищує надійність, продуктивність, урожайність та інші KPI. Ця стаття, навпаки, називає цю практику абсолютно шкідливою й такою, що може повністю отруїти весь процес розробки.
Основні причини НЕ проводити code review:
- неможливість оцінити час, який потрібен на виконання завдання;
- постійне провокування конфліктів, погіршення відносин у колективі;
- розмивання відповідальності;
- зайва витрата ресурсів.
Оцінювання часу
Колись давно вважалось, що вміння точно передбачити час, необхідний для виконання завдання, є обов'язковою навичкою програміста. Ясно, що в деяких ситуаціях (наприклад, при пошуку багу) це зробити важко, але у більшості випадків більш-менш можливо. Проблема код-рев'ю в тому, що воно в принципі позбавляє сенсу будь-яку оцінку. Хід рев'ю неможливо передбачити: можливо, потрібно буде виправити пару символів, а може, рев'ювер вимагатиме повної перероблювання завдання.
Крім того, неможливо оцінити, скільки часу займе сам перегляд коду.
Відносини у колективі
Почнемо з прикладу: одного разу я був свідком, як один розробник після отримання зауваження, пішов до рев'ювера і почав йому щось довго і нудно розповідати. Фактично це було компостування мозку, яке тривало півтори години та виявилось дуже дієвим — потім цей рев'ювер вже ніяких зауважень розробникові не робив.
У командах, які практикують рев'ю коду, відбувається всяка погана річ:
- самоствердження шляхом менш конфліктних людей та «дідівщина»;
- помста: «хтось посмів зробити мені зауваження, завтра я йому зроблю два»;
- коаліції: «ми з товаришем затверджуємо одне одного, а всім іншим ставимо мінуси»;
- суперництво: «я свою фічу ніяк не завершу, а колега вже дві зробив, хай тепер переробляє».
Результатом цього всього є демотивація та вигорання. Ще один випадок з життя: одного разу мені щось не сподобалось у рев'ю, але я не став про це відразу казати, бо знав, що автор того коду — людина досить вперта і мстива. Тому я трохи почекав, поки в іншого мого колеги буде гарний настрій, пішов до нього і розповів про проблему та про методи її вирішення. Вмовив і потім ми разом пішли вмовляти автора коду. Після такої хитрої комбінації вдалось добитися втілення одного зауваження з трьох. Ясно, що після того я вже ніякі зауваження старався не робити.
Розмивання відповідальності
Тут справа не в тому, щоб шукати винних — все одно більшість з нас нічого не втратить, якщо десь з'явиться якийсь баг.
Проблема в тому, що люди бояться приймати рішення. Вони думають, що десь там (може навіть в іншій команді) знайдеться мудра досвідчена людина, яку можна запитати й вона скаже, як правильно робити. Це хибний шлях. Якщо ви проаналізуєте варіанти рішення, виберете один, реалізуєте й оціните результат — в нагороду отримаєте досвід. Якщо перекладете це на когось іншого — досвід буде втрачено.
Витрата ресурсів
Очевидно, що рев'ю забирає час розробників. Крім того, потрібен окремий сервер для системи, за допомогою якої роблять рев'ю та людина для догляду за ним.
Проблема в тому, що перегляд коду в принципі не може бути ефективним. Є такий закон тривіальності (англ. «bike-shed effect»): чим менше значення має якась деталь, тим більше її будуть обговорювати. Для нас це означає, що люди годинами сперечатимуться про назви змінних або довжину методів в той час як реально важливі речі пройдуть поза увагою.
Інші аргументи
Прихильники code review вважають, що завдяки цій практиці серед членів команди відбувається розповсюдження знань про код. В цілому це правильно, але є одне але: рев'ювер бачить лише фінальний результат. В процесі вирішення завдання розробник зустрічається з різними невідповідностями та неочевидними проблемами, під час вирішення яких і формується «знання коду». Рев'ювер цих проблем не побачить, поки сам не почне щось втілювати, відповідно, справжнього досвіду у нього не буде.
Також кажуть, що code review сприяє «загальному покращенню коду» і це геть невірно. Річ у тім, що погані рішення розповсюджуються з тою ж силою, що й добрі. Наприклад, у мене був випадок, коли я отримав зауваження, повірив рев'юверу на слово і виправив код. Потім я в такій же ситуації теж почав робити зауваження іншим людям, і вони їх виконували. Але пізніше я детальніше розглянув ту ситуацію і виявив, що перший рев'ювер помилявся — і в результаті тієї помилки всі змінили купу коду у неправильний спосіб.
Насправді єдина ситуація, де перегляд коду стає у пригоді — навчання джуніорів. Там можна уникнути конфліктів завдяки чітко сформульованим відносинам майстер-підлеглий, а додаткові витрати є частиною процесу. В інших випадках впровадження практики обов'язкового code review призведе до отруєння команди та руйнування проекту.
Наостанок мовне питання: як на мене, у Вікіпедії code review вдало переклали як «перегляд коду». Також можна зустріти варіант «код-рев'ю» та ще кілька інших.
Ще немає коментарів