Как «нейтрализовать» тех, кто пишет плохой код в команде?

9

Мне всегда нравилась эта статья на JoelOnSoftware под названием «Готовимся, когда ты только хрюкаешь». Я мог особенно относиться, когда я был новичком (и все еще чувствую, что я ВСЕГДА буду одним).

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

team bug С Джонсон
источник
1
Оружие. Многие из них.
CodesInChaos

Ответы:

9

Постоянная оценка.

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

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

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

П Швед
источник
2
Отличный ответ. Если я могу просто добавить к этому, если этот человек является сверстником, то это лучше всего сделать руководителем группы. Таким образом, ответ «не хорошо, сделай это снова» был бы намного более эффективным, если бы им командовала иерархия магазина.
1
@ Серфер, все с точностью до наоборот. Вы становитесь лидером команды, делая такие вещи, предлагая лучшие решения, заботясь о том, что делает команда. Не наоборот. (Но, конечно, помогает помощь на более высоких уровнях иерархии).
П Швед
1
Таким образом, возникает вопрос, кто имеет право заставить их переписать это? Я думаю, что ответ, моральный авторитет всей команды, если проблемы передаются всей команде.
С Джонсон
В отсутствие надежного механизма проверки кода для каждого члена команды это уместно. Также целесообразно убедиться, что бозо не выкапывает действительно глубокую яму (даже не стоившую затрат на ремонт), прежде чем его попросят переделать.
Mattnz
5

Если человек просто не знает ничего лучше, но хочет учиться, обеспечьте некоторое наставничество и проверку кода. Убедитесь, что они подвергаются воздействию хорошего кода.

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

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