Чому не треба проводити code review

5 хв. читання

В інтернеті повно статей, в яких написано, що code review — надзвичайно гарна штука, яка підвищує надійність, продуктивність, урожайність та інші KPI. Ця стаття, навпаки, називає цю практику абсолютно шкідливою й такою, що може повністю отруїти весь процес розробки.

Основні причини НЕ проводити code review:

  • неможливість оцінити час, який потрібен на виконання завдання;
  • постійне провокування конфліктів, погіршення відносин у колективі;
  • розмивання відповідальності;
  • зайва витрата ресурсів.

Оцінювання часу

Колись давно вважалось, що вміння точно передбачити час, необхідний для виконання завдання, є обов'язковою навичкою програміста. Ясно, що в деяких ситуаціях (наприклад, при пошуку багу) це зробити важко, але у більшості випадків більш-менш можливо. Проблема код-рев'ю в тому, що воно в принципі позбавляє сенсу будь-яку оцінку. Хід рев'ю неможливо передбачити: можливо, потрібно буде виправити пару символів, а може, рев'ювер вимагатиме повної перероблювання завдання.

Крім того, неможливо оцінити, скільки часу займе сам перегляд коду.

Відносини у колективі

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

У командах, які практикують рев'ю коду, відбувається всяка погана річ:

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

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

Розмивання відповідальності

Тут справа не в тому, щоб шукати винних — все одно більшість з нас нічого не втратить, якщо десь з'явиться якийсь баг.

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

Витрата ресурсів

Очевидно, що рев'ю забирає час розробників. Крім того, потрібен окремий сервер для системи, за допомогою якої роблять рев'ю та людина для догляду за ним.

Проблема в тому, що перегляд коду в принципі не може бути ефективним. Є такий закон тривіальності (англ. «bike-shed effect»): чим менше значення має якась деталь, тим більше її будуть обговорювати. Для нас це означає, що люди годинами сперечатимуться про назви змінних або довжину методів в той час як реально важливі речі пройдуть поза увагою.

Інші аргументи

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

Також кажуть, що code review сприяє «загальному покращенню коду» і це геть невірно. Річ у тім, що погані рішення розповсюджуються з тою ж силою, що й добрі. Наприклад, у мене був випадок, коли я отримав зауваження, повірив рев'юверу на слово і виправив код. Потім я в такій же ситуації теж почав робити зауваження іншим людям, і вони їх виконували. Але пізніше я детальніше розглянув ту ситуацію і виявив, що перший рев'ювер помилявся — і в результаті тієї помилки всі змінили купу коду у неправильний спосіб.

Насправді єдина ситуація, де перегляд коду стає у пригоді — навчання джуніорів. Там можна уникнути конфліктів завдяки чітко сформульованим відносинам майстер-підлеглий, а додаткові витрати є частиною процесу. В інших випадках впровадження практики обов'язкового code review призведе до отруєння команди та руйнування проекту.

Наостанок мовне питання: як на мене, у Вікіпедії code review вдало переклали як «перегляд коду». Також можна зустріти варіант «код-рев'ю» та ще кілька інших.

Помітили помилку? Повідомте автору, для цього достатньо виділити текст з помилкою та натиснути Ctrl+Enter
Codeguida 6.2K
Приєднався: 7 місяців тому
Коментарі (0)

    Ще немає коментарів

Щоб залишити коментар необхідно авторизуватися.

Вхід / Реєстрація