Как вести себя с разработчиком, который возражает против наших обзоров кода как «грубый, снисходительный или иным образом токсичный»? [закрыто]

Я почти уверен, что это отступает от предыдущих вопросов, но, будучи на месте обеих сторон, я бы дал старшему разработчику некоторую презумпцию подсказки и работал с ними, чтобы преобразовать их жалобы в конструктивные действенные рекомендации по улучшению и иметь все следят за этими улучшениями процесса и контролируют с каждой участвующей стороной, довольны ли они улучшением:

1. Откровенно говоря, довольно многие обзоры кода являются «грубыми, снисходительными или иным образом токсичными», если люди, которые их делают, недостаточно опытны, плохо общаются, мелочны, невежественны, ленивы, полное отсутствие руководств, программного процесса, документации. , письменные протоколы, последующие действия... ваша работа заключается в том, чтобы преобразовывать жалобы в конструктивные улучшения. Я не понимаю, почему вы, кажется, автоматически сомневаетесь во всем, что говорит ваш разработчик, и отвергаете их как плаксу, даже если они не говорят это оптимальным образом или не тем сторонам. Ради бога, не ожидайте, что HR будет предлагать конструктивные улучшения вашего программного процесса. В истории программного обеспечения я никогда не слышал об этом. Если только обзоры кода не являются обзыванием детского сада.

2. Ваши три предложенных варианта ограничены суровостью, принуждением и снисходительностью, я боюсь, что не было варианта «Активно выслушивать жалобы разработчиков и помогать переформулировать их в конструктивные изменения: «Как мы можем улучшить наш процесс проверки кода / процесс разработки программного обеспечения? Устранить повторение? Собрать и формализовать нашу базу знаний/кодовую базу? Улучшить документацию?». Это критика вашего стиля слушания. Итак, вы думаете, что они должны были быть в состоянии с этим смириться, потому что вы могли... остерегайтесь снисходительности, у всех нас есть свои слабости, сдерживайте свое эго... предположительно есть вещи, которые они могут сделать легко, которые вы можете найти невозможными. Если вам действительно трудно с ними общаться, поговорите с ними наедине и проясните ситуацию. Конструктивно. Иногда некоторые из моих наиболее надоедливых коллег научили меня полезным вещам. Даже если бы мне пришлось расшифровывать их клубок эмоций.

3. «даже подвергать сомнению решения, принятые на предыдущих встречах»Ну, если это правда, кто ведет (краткие) протоколы этих встреч? в той же системе документации, что и проверки кода? (JIRA? git? Bugzilla? вики? Mondrian? GoogleDoc?) Если никого нет, назначьте кого-нибудь как можно скорее. Если кто-то делал это, но плохо, скажите ему, чтобы он сделал это правильно, или переназначьте просьбу (но остерегайтесь вознаграждать плохое поведение). Опять же, это законная конструктивная жалоба/предложение по улучшению. Код-ревью — это не закулисные занятия для новичков. Не позволяйте новичкам перекладывать ответственность за обучение на старших разработчиков и на проверку кода. Кроме того, есть ли у вас встречи, которые не приводят к решениям или действиям? Это еще один распространенный организационный антипаттерн. Является ли комментарий решением? Правомерно ли групповое голосование? Когда ошибается большинство? и т. д.

4. одно мощное предложение (особенно когда общаются ботаники) состоит в том, чтобы переформулировать вопросы/критику, чтобы сосредоточиться на вещах, а не на людях, и, в частности, обезличить вопросы/разногласия : например * «Почему ваш код делает X? Почему вы реализовали Y как A вместо Б?» -> "Каковы причины того, что строки LLL делают X? Почему лучше реализовать Y...?"

5. В качестве общего процесса и для того, чтобы научить всех, что ваш процесс принадлежит сообществу , попросите младших ребят (особенно) начать читать кучу книг по улучшению процесса кодирования и проверки, например. «Code Complete: Практическое руководство по созданию программного обеспечения, второе издание», особенно. Часть V. Попросите их улучшить процесс. Заставьте их документировать повторяющиеся вопросы (пусть они создадут вики). И так далее. Спросите разработчика, помогают ли эти улучшения.

6. Также в частном порядке попросите своего разработчика (и его менеджера) всегда пытаться переформулировать жалобы в запросы на изменение процесса («активное слушание» — один из многих методов. Базовое сочувствие тоже всегда помогает). Возможно, им будет полезна какая-нибудь книга или курс. Если ситуация дошла до отдела кадров, это также говорит мне о том, что вовлеченный менеджер не умел справляться с такими вещами. Итак, вы все должны извлечь из этого урок. Не вешайте это на разработчика.

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

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

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

Это звучит плохо. Ваша проблема в том, что вы разработали совершенно неподходящий метод обучения младших сотрудников. Роль рецензента заключается в улучшении рецензируемого кода. Проверка кода не предназначена для обучения людей. Обучение предназначено для обучения людей. И старшие разработчики не являются тренерами. Если вы хотите, чтобы кто-то обучал ваших младших разработчиков, наймите тренера. Не старший разработчик программного обеспечения.

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

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

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

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

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

Особая благодарность @Lilienthal за указание на то, что я, возможно, упустил из виду возможность наличия недостатков в наших существующих процессах, что я полностью отклонил, но на самом деле не должен был.

Без код-ревью его коллеги просто изменят его код (не сказав ему об этом) или побоятся коснуться его части кодовой базы.

В agile-магазине ни один из этих вариантов нежелателен.

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

Потенциальные разногласия и недоразумения, которые выявляются при проверке кода, не создаются проверками кода.

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

Это сказано из комментариев вашего разработчика:

мы делаем их индивидуально с наших столов. Я всегда всем говорю, что готов обсуждать вещи более подробно, но в итоге мы просто пытаемся ввести миллион строк текста в систему Visual Studio/TFS – DefunctNinja

Похоже, что DefunctNinja описывает вовсе не обзоры кода , и, возможно, проблема в этом.

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

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

Скорее всего, они просто выпалили первое, что пришло им в голову при чтении кода во время сеанса видеоконференции, отсюда отсутствие у них фильтров и такта. Так что на самом деле это вовсе не тщательно продуманная сессия проверки кода, а скорее бесконечная дискуссия о догадках «велосипедного сарая».

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

Паркинсон объясняет это тем, что атомная установка настолько велика, настолько дорога и настолько сложна, что люди не могут ее понять, и вместо того, чтобы попытаться, они полагают, что кто-то еще проверил все детали, прежде чем дойти до этого. Ричард П. Фейнман приводит в своих книгах пару интересных и очень точных примеров, касающихся Лос-Аламоса.

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

В Дании мы называем это «установкой отпечатка пальца». Речь идет о личной гордости и престиже, о возможности указать куда-то и сказать: «Вот! Я сделал это». Это сильная черта политиков, но она присутствует у большинства людей, которым предоставляется шанс. Только подумайте о шагах на мокром цементе.

источник