Как вы разоружаете ковбойского кодера? [закрыто]

Я нашел вопрос (кодовый ковбой в команде), но он был больше связан с «Ninja Coder», чем с проблемой, с которой я столкнулся.

У меня есть член команды, который является живым примером « Ковбойского кодера ». Я понимаю, что нельзя изменить людей, но есть ли способ заставить его перестать вести себя как «Ковбой-кодер»?

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

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

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

Как я могу разоружить этого ковбойского кодера?

Я чувствую, что я последний, кто действительно заботится о проекте вообще.

Я вижу несколько вариантов:

• Подойдите к кодеру со своими проблемами. Это должно быть сделано как конструктивная критика с конкретными моментами. Прежде чем предпринимать более масштабные шаги, уместно поднять вопросы напрямую и в частном порядке, чтобы дать человеку возможность измениться.
• Соберите информацию и статистику и представьте ее руководству. Менеджмент может показаться неважным, но часто важно приложить усилия в любом случае, если это работает. Возможные негативные последствия включают отчуждение других, которые не ценят жалобы к руководству.
• Найдите сверстника ковбоя и обсудите это наедине. У него / нее может быть больше шансов заставить человека слушать.
• Попросите поработать в другой команде. Не решит проблему, но вы сохраните здравомыслие. По крайней мере, всегда работайте в меру своих способностей и не позволяйте им тянуть вас вниз.
• Покиньте организацию, если никто не послушает. Это звучит как плохая обстановка.

Он отказывается слушать команду, и недавно он прекратил проверки кода, модульное тестирование, поделился подробностями реализации ...

При проверке кода не обязательно, чтобы кодировщик отправлял работу на проверку.

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

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

Код исходит из требований. Требования приводят к выполнению тестов, которые проверяют выполнение требований. Эти тесты могут быть дополнительно разбиты и могут быть записаны до внесения изменений, чтобы убедиться, что изменения соответствуют требованиям (красно-зеленый-рефактор; сущность TDD).

Добавьте метрику «покрытия кода» на сервер сборки вашей команды (надеюсь, у вас есть такой; если нет, то это ваша первая проблема). Простая проверка прохождения модульных тестов не обнаружит проблем с его новым не-TDD-кодом, созданным в областях, где нет модульных тестов. После запуска всех модульных тестов сервер сборки должен в идеале выполнить каждую строку кода, но на самом деле есть некоторые вещи, которые вы просто не можете выполнить модульным тестом. Реально, вы все равно должны ожидать 95% покрытия или выше (или исключить определенные библиотеки или типы файлов из покрытия). Рано или поздно ваш ковбой проверит что-то, что нарушит сборку, потому что он опустил уровень покрытия ниже порогового значения, и вы вызываете его.

А что касается «скорости», то скорость - это скорость, с которой вы «делаете», и это не «делается», пока не будет сделано правильно. Вы можете передать это своим менеджерам таким образом; рассмотрим автомеханика, который, когда менеджер берет свою БМВ, чтобы получить замену масла, забывает вытащить заглушку масляного поддона, и в результате все новое масло выливается, прежде чем он даже выезжает из гаража. Конечно, замена масла заняла всего пять минут, но менеджер не будет заботиться об этом, когда двигатель его машины заедает по дороге домой. Он позаботится о том, чтобы механик пропустил шаг, что потребует от него много дополнительного времени и денег для ремонта. Прямо сейчас он платит одному ковбою, чтобы он сделал работу очень быстро, а затем он Выплачивает остальной команде гораздо большую сумму, чтобы прийти и правильно выполнить работу. В чем на самом деле преимущество того, чтобы ковбой продолжал делать свое дело?

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

Позвони ему. Когда вы найдете что-то, что он испортил, покажите ему, как работает его код, как он мог предотвратить проблему в первую очередь (включая правильный дизайн, TDD, проверки кода) и что вы были или должны будете сделать в результате исправить его неработающий код.

Я чувствую, что я последний, кто действительно заботится о проекте вообще.

гудки клаксонов, мигающие огни, вопли сирен - если вы действительно чувствуете, что вы единственный человек, который заботится о качестве кода, созданного командой, тогда возникает СЕРЬЕЗНАЯ проблема. Если вы чувствуете, что пытаетесь втянуть всю команду, пиная и крича, в эру хорошего кодирования, и это слишком большой вес, чтобы его тащить, тогда отбросьте его. Если в компании есть другая команда, которая делает все правильно, попросите о переводе, в противном случае, черт возьми.

Перейдите к руководству со своей статистикой о том, сколько ошибок / проблем исходит от этого одного разработчика. Объясните им, что исправление их ошибок влияет на производительность вашей команды. Если действительно 80% проблем исходит от одного человека, это определенно необходимо решить. Пока вы объясняете это руководству в терминах, с которыми они могут согласиться (т. Е. «Потраченное время - это потраченные деньги»), они будут вмешиваться.

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

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

Давление со стороны сверстников и личный пример - единственные хорошие способы. Лучшие способы сделаны их боссом / лидером. Если вы не их начальник / лидер, то поговорите с теми, кто есть. Но в конце концов это их дело, а не твое. Удостоверьтесь, что вы делаете хорошую работу, и вещи имеют тенденцию работать самостоятельно.

Он отказывается слушать команду, и недавно он прекратил проверки кода, модульное тестирование, поделился подробностями реализации ...

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