Код-ревью, как способ развалить команду.

Через форму обратной связи несколько раз подряд задали один и тот же вопрос. Формулировки разнятся, но суть не меняется. Многим не нравится процесс код-ревью и "токсичный" тон этих ревью.

Наболело о том как делают код ревью.

Почему так и что с этим делать?

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

Где-то ревью превращались в удобный инструмент для общение и документации решений. В одной из команд пулл-реквест был своеобразным RFC. Девелопер создавал его ещё до того, как был написан какой-то код. В описании рассказывался примерный путь решения проблемы, а каждый сокомандник мог заглянуть и в любое время что-то посоветовать или указать на потенциально проблемные решения. В той же команде мы практиковали парное программирование. В итоге атмосфера была очень дружелюбная, и даже несколько лет спустя мы общаемся и встречаемся с сокомандниками.

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

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

Я видел, как ввод обязательного код-ревью приводил к тому, что дружная команда превратилась в людей, которым неприятно сидеть за соседними столами. За год члены команды прекратили всё общение вне работы, тогда как до этого они были дружны и в гости друг к другу ходили регулярно. Проблема была в том, что команда не умела ревьюить чужой код, и не хотела понимать смысл ревью. Упс.

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

Если же тебя в целом всё устраивает, но в команде есть один-два человека, которые отравляют процесс, то можно и попытаться решить эту проблему. Как правило ты ничего не теряешь. Получится? Вот и славно, будет что рассказать на STAR интервью. А если не получится, то ты всегда сможешь уйти.

Ищем союзников

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

Кто может встать на твою сторону? Ну вообще говоря, любой заинтересованный человек, сколько нибудь ответственный за продукт. Тимлид, ПМ и просто инженеры твоего уровня.

Подобная ситуация:

[Мне] некомфортно выслушивать эти критиканские высказывания, меня ['токсичный' коллега] слушать не будет, и я не знаю, кому "пожаловаться", чтобы он, как минимум, перестал выражаться критично и как будто ему все должны и должны делать так, как он велит. Но и терпеть этот, извините, эгоцентричный пиздец я тоже не хочу.

Означает лишь то, что скоро кто-то уйдёт из команды, унеся с собой экспертизу и знания. А остальным придётся задуматься над возросшей нагрузкой. И... как это часто бывает, они примут правильное решение, и уйдут в другую компанию.

Если ты столкнулся с такой ситуацией, то логичнее всего было бы обозначить её своему менеджеру или тимлиду. Кто там у тебя есть? В идеале, конечно, сделать это на 1-1 митинге, если они проводятся в команде.

Зависит от уровня доверия и профессионализма твоего менеджера, но указать ему о проблеме — твоя обязанность. На модном сленге тимлидов это называется "послать сигнал". Вот пусть он этот сигнал ловит и работает над решением конфликта.

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

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

Бум! Тут ты, конечно, не говоришь про токсичные доебы и формулировки, а акцентируешь внимание на потерях времени. Но все же понимают, о чем разговор.

Линтер

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

К сожалению, это не так. Да, расстановку скобочек и пробелов можно как-то заавтоматизировать. Можно даже нейминг чуть поправить. Но код он в целом очень субъективен. Что-то может показаться попросту некрасивым.

В итоге у вас постоянно будут возникать трения по поводу правил, которые не описаны в конфиге линтера. Бороться надо с причиной, увы.

Замена код-ревью

Плохие код-ревью не сильно помогают команде. Однако, вторая пара глаз — слишком ценный инструмент поиска ошибок. Может стоит дать шанс парному программированию? Вводить его можно не сразу, и не на 100%.

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

Чем хорош такой вариант? Во-первых, те, кто испытывают дискомфорт от плохого код-ревью будут иметь шанс продуктивно работать без необходимости продираться через неприятные комментарии.

Во-вторых, это позволит членам команды лучше друг-друга узнать. В лицо вам никто не скажет, что ты тут написал какое-то говно. В таком случае, ты сразу передашь клавиатуру напарнику, и позволишь ему самостоятельно выразить свою мысль. Заодно он сможет объяснить тебе почему он считает такое решение лучше или правильнее.

Разгрузка разработчиков

Через некоторое время, ревью превращается в повинность, которую не любят абсолютно все члены команды. Она занимает много времени, нужно постоянно менять фокус и контекст. Нужно вникать в то, что там написал твой товарищ. Как результат — ревью откладывается на потом.

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

Как тут быть? Ищите свой путь. Лимитируйте количество work in progress тикетов. Следите за очередью на ревью. Замеряйте время ожидания и время на фиксы. Вводите правила: ревью затрагивает лишь тот код, который поменялся. Привыкайте к тому, что некоторые замечания по ревью могут быть выполнены в отдельной ветке и в отдельном PR.

Пытаемся понять коллегу

Есть такой момент: читают не всегда то, что пишут. Возможно, коллега вовсе и не токсичный пидорас, а всего лишь человек, который плохо умеет выражать свои мысли. Это бывает. Ему сложно описать почему он считает какой-то подход правильным. Возможно, он где-то слышал или ему кто-то более опытный рассказал о том, как надо писать код.

Агрессивные ревью — часто признак неуверенности в своих знаниях. Почему-то чаще всего этим грешат посредственные инженеры, хотя и звёзды тоже замечены в таких делах. Но, что-то мне подсказывает, что скорее всего твой коллега не работает в гугле :)

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

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

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

Впрочем, даже если и ты и твой знакомый ужаснулись от уровня комментариев, это ещё не значит, что твой оппонент пишет из со злости. Возможно, он просто такой вот гик, который не воспринимает чужие эмоции. Наверняка, помнишь историю с Линусом Торвальдсом, который 20 лет хуесосел всех вокруг, а потом отправился учится воспринимать чужие эмоции. Штош, может себе позволить.

Выводы.

Если ты тимлид или менеджер — следи за процессами. Замеряй и постоянно общайся с командой. Следи за их настроением, за тоном общения. Прививай культуру. Иначе пересрутся и разбегутся.

Если ты ревьюер — думай о причинах и мотивах коллеги. Оценивай "стоимость" исправлений.

Если тебя ревьюят — не ругайся в пулл-реквесте. Вовремя сигнализируй о проблеме и делегируй решение тем, кому за это платят (тимлиду, например).

Посты на эти и другие темы публикую в канале: https://t.me/your_soft_skillzz

и твиттере https://twitter.com/soft_skillzz

Задать вопрос или предложить тему для новых постов: https://goo.gl/forms/1G2206MfVzfoowHf2

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

МS.