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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Уволить их

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

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

Понимаю

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

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

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

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

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

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