Он отказывается слушать команду, и недавно он прекратил проверки кода, модульное тестирование, поделился подробностями реализации ...
При проверке кода не обязательно, чтобы кодировщик отправлял работу на проверку.
Самый простой способ отследить, что он делает, - следить за историей VCS и искать его регистрации. Если вы беспокоитесь о его коде, это простой способ найти его. Получите историю изменений, посмотрите, что он вставил, и посмотрите, не выпрыгнут ли на вас красные флажки. Поймайте его проверки достаточно быстро, и если вы обнаружите проблему, вы можете откатить коммит и отправить его по электронной почте. Вам разрешено вызывать членов вашей команды, даже если вы младший кодер, когда вы видите что-то явно не так.
Да, он быстро «кодирует», но его код - всего лишь генератор ошибок. Другие члены команды и я находимся в «фазе исправления ошибок», и 80% ошибок происходит из его кода. Я не хочу исправлять его ошибки. И менеджмент слеп, или не хочет этого видеть, или, может быть, им нравится его «скорость».
Код исходит из требований. Требования приводят к выполнению тестов, которые проверяют выполнение требований. Эти тесты могут быть дополнительно разбиты и могут быть записаны до внесения изменений, чтобы убедиться, что изменения соответствуют требованиям (красно-зеленый-рефактор; сущность TDD).
Добавьте метрику «покрытия кода» на сервер сборки вашей команды (надеюсь, у вас есть такой; если нет, то это ваша первая проблема). Простая проверка прохождения модульных тестов не обнаружит проблем с его новым не-TDD-кодом, созданным в областях, где нет модульных тестов. После запуска всех модульных тестов сервер сборки должен в идеале выполнить каждую строку кода, но на самом деле есть некоторые вещи, которые вы просто не можете выполнить модульным тестом. Реально, вы все равно должны ожидать 95% покрытия или выше (или исключить определенные библиотеки или типы файлов из покрытия). Рано или поздно ваш ковбой проверит что-то, что нарушит сборку, потому что он опустил уровень покрытия ниже порогового значения, и вы вызываете его.
А что касается «скорости», то скорость - это скорость, с которой вы «делаете», и это не «делается», пока не будет сделано правильно. Вы можете передать это своим менеджерам таким образом; рассмотрим автомеханика, который, когда менеджер берет свою БМВ, чтобы получить замену масла, забывает вытащить заглушку масляного поддона, и в результате все новое масло выливается, прежде чем он даже выезжает из гаража. Конечно, замена масла заняла всего пять минут, но менеджер не будет заботиться об этом, когда двигатель его машины заедает по дороге домой. Он позаботится о том, чтобы механик пропустил шаг, что потребует от него много дополнительного времени и денег для ремонта. Прямо сейчас он платит одному ковбою, чтобы он сделал работу очень быстро, а затем он Выплачивает остальной команде гораздо большую сумму, чтобы прийти и правильно выполнить работу. В чем на самом деле преимущество того, чтобы ковбой продолжал делать свое дело?
Есть ли способ, которым я (как его младший коллега по возрасту, а не его начальник) могу что-то с этим сделать?
Позвони ему. Когда вы найдете что-то, что он испортил, покажите ему, как работает его код, как он мог предотвратить проблему в первую очередь (включая правильный дизайн, TDD, проверки кода) и что вы были или должны будете сделать в результате исправить его неработающий код.
Я чувствую, что я последний, кто действительно заботится о проекте вообще.
гудки клаксонов, мигающие огни, вопли сирен - если вы действительно чувствуете, что вы единственный человек, который заботится о качестве кода, созданного командой, тогда возникает СЕРЬЕЗНАЯ проблема. Если вы чувствуете, что пытаетесь втянуть всю команду, пиная и крича, в эру хорошего кодирования, и это слишком большой вес, чтобы его тащить, тогда отбросьте его. Если в компании есть другая команда, которая делает все правильно, попросите о переводе, в противном случае, черт возьми.