Как бороться с кем-то, кому не нравится идея проверки кода?

26

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

Но всегда есть те парни (или девчонки), которые сопротивляются каждой унции своего существа.

Как вы эффективно справляетесь с этим сценарием, работая с ним в качестве рецензента?

Ozz
источник
19
Вероятно, точно так же, как вы имеете дело с людьми, которые ссорятся с другими вещами, такими как дресс-код, своевременность, больничные и т. Д.
Джош К
хе-хе .... Я постарался уточнить, что, говоря о том, что все должны это делать, я все время пытаюсь понять, что мне нужно, чтобы вы, простой рецензент, попытались сделать это.
Оз
3
Честно говоря: Скажите им, чтобы заткнуться и сделать это. Это для их же блага.
Стивен Эверс
1
Сопротивление чему? Позволяет вам увидеть их код или они смотрят на ваш? Они могут избегать конфликтов, могут ли они ожидать конфликта? Вы знаете, почему они колеблются?
Мартин Маат

Ответы:

46

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

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

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

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

Майкл К
источник
3
Возможно, вы захотите добавить определение «мозг ящерицы» для людей, незнакомых с ним.
Адам Лир
@ Анна: Я только что добавил ссылку на определение.
Потрясающий ответ Пьер! За проголосовали вместо окончательного ответа.
Оз
1
@ Аарон: я ссылался на «кого-то», упомянутого в вопросе. Да, у меня все еще иррациональные страхи из-за состояния здоровья как в моем ребенке, так и во взрослой жизни, как и у большинства из нас. Примеры: у меня иррациональный страх перед максимумами. Я уменьшаю чувствительность, когда могу. В прошлые выходные я посетил цитадель (очень распространенную в моей стране из-за войны между французами и немцами), и мне пришлось съездить на трамвае.
1
Как обычно отличный ответ Пьера.
Джош К
5

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

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

Майкл К
источник
Парное программирование - это совсем другая тема, но отличное предложение!
Оз
Ваши комментарии заставили меня задуматься о PP, поэтому я начал еще один Q - programmers.stackexchange.com/questions/39878/… Спасибо!
Оз
4

Ответ @ Pierre является правильным для того, кто боится пересмотра кода. Я могу представить себе другую ситуацию. Звездный программист, который чувствует пересмотр кода, является пустой тратой времени, потому что там код достигает приемлемого стандарта качества и правильности. В этом случае они могут чувствовать, что проверка кода - это трата времени и охота на ведьм. (Это поиск проблемы, когда ее не существует.)

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

Hogan
источник
5
С этим типом людей вы могли бы попытаться сообщить им, что вы взволнованы просмотром их кода, потому что вы думаете, что многому научитесь у них. Обзор кода заключается не только в улучшении кода, но и в том, чтобы показать другим членам команды лучший код, который поможет им в дальнейшей разработке.
HLGEM
2

Честно говоря, этот вопрос не имеет никакого смысла, если у вас хорошо управляемый магазин:

1) Если это часть работы, вы должны это сделать, или вы не подчинены. Тот, кто категорически отказывается выполнять часть работы, которую он должен выполнять, должен получить консервы. Программирование - это ремесло и профессия - рецензенты и менеджеры всегда готовы помочь, а не справиться с испорченными детьми (любого возраста).

2) Если у вас хорошо управляемая система контроля версий (что необходимо в любом профессиональном магазине программного обеспечения), то их код можно просмотреть независимо от того, нравится им это или нет. Итак, просмотрите их код:

  • Если это хорошо, уведомите их и похлопайте по спине - это будет стимулировать участие.

  • Если это не хорошо, также дайте им знать. Это должно побудить их к участию, чтобы защитить себя. Если этого не произойдет, вы можете использовать карательные меры: финансовые штрафы, понижение в должности и т. Д. Если, несмотря на ваши усилия, этот сотрудник не может прийти в себя, IMO, у вас плохой сотрудник, и им нужно показать дверь.

Вектор
источник
Это совершенно безнадежный совет, я предвижу «магазин» с действительно плохой рабочей средой для вас. Urgghh!
коньяк
@cognacc - Вам не нужно ничего «предвидеть». Я работаю в группах в течение 25 лет, где у нас очень хорошая рабочая среда: мы все взрослые и понимаем, что нужно для того, чтобы быть профессионалом и нести ответственность за свою работу.
Вектор
1
Я должен согласиться с вектором. Если это часть процесса, все это делают, и я уверен, что они быстро увидят, что «это не кусает». Конечно, всегда существует риск того, что некоторые люди будут «грубыми» в своих комментариях в обзоре кода, но тогда с этими людьми нужно иметь дело - так же, как если бы они были грубыми со своими коллегами лично.
MetalMikester
Я согласен с коньяком, это бесполезный совет, потому что он не предлагает стратегии или решения. Он просто говорит «они должны, потому что они должны». Duh. Вопрос в том, как с ними бороться, как в том, как их перевернуть. Просто заставлять людей делать что-то против их воли (или иначе) - это не решение проблемы, а скорее создание новых. Сначала вы должны понять происхождение сопротивления.
Мартин Маат
Вы пропустили мое замечание хорошо управляемый магазин и все, что следует из него: это означает, что вы имеете дело со взрослыми: людьми, которые знают, что означает и что означает их работа. Вы не поняли мой совершенно ясный ответ.
Вектор
1

Есть ли у них негативный опыт в местах, где проверки кода не были выполнены должным образом? У них могут быть законные проблемы.

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

Code Review «должен» улучшить разработку, но до тех пор, пока у вас не появится система, которая действительно работает, зачем кому-то захочется это делать?

JeffO
источник
Спасибо, Джефф, согласись, если процесс будет бесполезным, он будет трудным, и обойти чьи-то иррациональные страхи может быть сложно - некоторые люди просто не изменятся!
Оз
1
но до тех пор, пока у вас не появится система, которая действительно работает, зачем кому-то хотеть это делать? Позвольте мне сделать дикий удар по этому: Сделайте это, чтобы вы могли понять, почему ваша система не работает ?
Вектор
1
@Vector - Если вы программисты, не можете понять, как заставить это работать, у них могут быть большие проблемы. Я также думаю, что руководство должно взять на себя некоторую ответственность и дать четкое определение качественного кода. Если код, который выходит, не содержит слишком много ошибок, у них может быть веская причина не включать проверку кода. Для проекта любой сложности, я сомневаюсь, что это происходит без проверки качества кода или, возможно, непропорционально большого количества времени и затрат на разработку.
Джефф
@JeffO - Хорошо, я понимаю вашу точку зрения: если система действительно не работает, это не вопрос «проверки кода», вопрос в компетенции программистов, и поэтому простой «просмотр кода» не является решением. Я согласен с этим.
Вектор
1

Я лично, что есть некоторые бои, которые просто невозможно выиграть со 100% населения.

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

Но обзоры кода разные - они меняют вашу производительность, а не обязательно ваши рабочие привычки.

Руководство может сделать несколько вещей, чтобы уменьшить сопротивление из-за производительности: 1) Принять снижение скорости для всех разработчиков. 2) Предоставить соответствующие инструменты для управления и слияния нескольких версий из-за циклов обзора (например, позволяя разработчикам иметь локальный git-репозиторий). 3) Обеспечить некоторую социальную или иную форму давления для обеспечения распределения нагрузки, качества и своевременности. обзоров.

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

Uri
источник
полностью согласен, Ури ... есть только некоторые люди, которых ты не можешь победить. Может быть, они настроены по-своему, ленивы, думают, что их путь верен, или просто все равно !!
Оз
0

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

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

Питер Б
источник
-1

Уволить их

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

Теперь, если вам кажется, что вы должны уволить 50% своей команды, тогда ...

Понимаю

Почему некоторые отказываются? У них нет времени? Они сгорели? Есть отзывы о чем-то, с чем у них нет опыта? Они думают, что это пустая трата времени, если так, то почему?

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

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

Все ли работают над одним и тем же проектом?

Проект уже похоронен под горой технической задолженности?

Верят ли они в проект и постоянное улучшение?

Дима Тиснек
источник
1
Хммммм ... так что не веря, что проверки кода дают больше пользы, чем затраты, автоматически означает, что человек не выполняет свою роль и не подрывает моральный дух команды, настолько, что его увольняют? Это довольно смелая позиция, основанная на отсутствии доказательств, однозначно подтверждающих претензию.
Данк
@ Данк, ты антирецензент? Тогда ты не будешь в моей команде. Вы рецензент? Тогда вы уже знаете поддержку моей претензии. Вы не определились? Пожалуйста,
решитесь
Я не являюсь антирецензентом, но я также понимаю, когда что-то не дает разумной выгоды относительно стоимости. Некоторым проектам / командам абсолютно необходимы официальные проверки кода, в то время как другие проекты / команды делают их только тогда, когда это считается полезным. Ваше предположение, что проверки кода всегда требуются, говорит о том, что вы даже не знаете реальных преимуществ и ограничений. Значит ты прав. Я не буду в вашей команде, и это будет большой потерей для вас.
Данк