Код ревью, как инструмент доминирования

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

После ввода обязательного этапа с ревью разработка чуть сбивает темп, люди притираются к новому процессу, входят во вкус. Конечно, это создаёт некоторые неудобства, но все стремятся к светлому будущему и понимают за что страдают.

К сожалению я неоднократно наблюдал, как реальность обрушивается на команду и код ревью превращается в токсичный инструмент выяснения отношений.

Современная разработка — это командная работа. А там где участвует больше одного человека, там живёт потенциальный конфликт. Это может быть личная неприязнь, может быть зависть, да и просто разница культур и мировоззений. Так или иначе, пустив дело на самотёк, ты сам не заметишь, как начнёшь ненавидеть код ревью.

Взяв пулл реквест на ревью ты получаешь странную власть над коллегой. Сейчас тебе решать, может ли он закончить работу над задачей и двигаться дальше, или же он будет тратить время на мелкие фиксы. Очень трудно не воспользоваться такой властью. Очень быстро борьба за чистоту проекта превращается в показательное выступление:

Смотрите, я — Д'Артаньян, и знаю как писать код, а вы все — беспомощные нажиматели кнопок.

Иногда всё это проходит в форме такой снисходительной вежливости, а иногда люди позволяют себе опускаться до прямых оскорблений. Вот смотри, каким тоном люди обсуждают чужой код:

Тут же полный набор:

вспомнили про университет (учился? значит должен соответствовать!)
начали унижать, предварительно задрав планку.
отметили собственное величие (я учился и я знаю, что так нельзя)

Такой классический приём психологического давления. Возможно, он используется неосознанно. Что ещё хуже, да?

Как проводить токсичные ревью?

Способов вредить коллегам, проводя ревью кода очень много.

Критиковать оформление кода (должен делать линтер\форматтер)
Критиковать незначительные детали (указал на не самый качественный нейминг в тестах, при этом ноль замечаний о сложном алгоритме)
Требовать обосновать то или иное решение, не предлагая альтернативу (почему ты написал так? не думал сделать по-другому? ~~со шрифтами поиграем?~~)
Требовать обосновать выбор решения, предлагая аналогичную альтернативу (я знаю, что есть абсолютно такая же библиотека, которая делает то же самое, почему ты выбрал не её?)
Завязывать долгие холивары с бросанием ссылками (твоя задача проверить код, на соответствие задачам, а не переубедить коллегу в превосходстве рекативного программирования над итеративным)
Просить поправить старый код, который слегка модифицирован в рамках решения задачи (этот код уже прошёл ревью, к задаче отношения не имеет. Нужно создать таску, а не заставлять девелопера отвлекаться)
Переходить на личности

Узнаёшь себя в любом из пунктов выше? Поздравляю, коллеги тебя ненавидят!

Что с этим делать? Если есть желание исправляться, то можешь попробовать осознать, что любой код — это плод борьбы с компромиссами и костылями, это результат дедлайнов и неудачных эстимейтов. Это результат интеллектуальной работы человека, который находится в постоянном стрессе, которого беспрестанно отвлекают.

Хорошего кода не бывает, бывает код, который решает задачу а бывает код который задачу не решает.

То, что ты считаешь хорошим кодом и хорошими практиками превратится в пшик через год-другой. Ты сам, посмотрев на свой собственный код спустя некоторое время, будешь плеваться. Так почему ты уважаешь свой опыт и свои идеи, но не ценишь опыт другого человека, который тоже уже собрал свой набор грабель? Просто подумай об этом.

Чуть в стороне стоит пункт про исправление существующего кода.

Слушай, раз уж ты тут, перепиши этот код нормально, а?

Это ужасный подход. Ты только что попросил человека разобраться со старым кодом, который уже прошёл ревью, пусть и давно. Этот код был оттестирован и проверен в бою. Это безумно раздувает скоуп задачи. Разработка современной системы и так похожа на бритьё яка. Зачем усугублять?

Как реагировать на токсичные ревью?

Возможно, ты сам становился объектом атак такого "доминатора". Как с этим бороться?

Для начала нужно понять, что пулл-реквест - это не площадка для дебатов о философии программирования. Лучше проглотить свою гордость, и выполнить требования. Что толку упираться и тратить время и нервы на мудака? Попутно придётся объяснять начальству почему задача так долго висит в In-Progress.

Не возможно выйти из такого спора победителем. Ты будешь выглядить упёртым бараном, неспособным на командную работу. Оно тебе надо?

Но необходимо замерять потери времени. Заставили поправить перенос строк? Отлично! Считаем, сколько времени ушло на переключение веток, фикс, CI цикл, ожидание следующего раунда ревью, мердж и раскатку по тестовому окружению. Вот с этими цифрами на руках и нужно начинать разговор на ретроспективе. Можно даже не указывать пальцем, а просто обозначить ситуацию, сообщив о "неэффективности наших код ревью". Можно даже решение предложить — давайте настроим линтер?

Нужны ли ревью кода?

Сложный вопрос. К сожалению, невозможно взять одну и ту же команду и сравнить как бы они писали код с код ревью и без него.

Ревью, как способ огородить репозиторий от некачественного кода, потенциально выльется в ситуацию, в которой главный идеолог превратится в такого Гэндальфа, старательно мешающего работать команде.

Команда, в свою очередь поймёт это, и будет искать пути наименьшего сопротивления. Либо образует свой кластер из лояльных ревьюеров. Либо просто завалит одного человека пулл реквестами, попутно снизив качество работы (зачем напрягаться, если в любом случае код отправят на доработку).

Но об этом мы поговорим подробнее в другой раз. Следите за обновлениями в канале https://t.me/your_soft_skillzz

Подписывайтесь и рассказывайте друзьям.

МS.