Что делать с разработчиком, который не тестирует свой код?[закрыто]

Question

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

Помимо избавления от разработчика, как я могу решить эту проблему?

РЕДАКТИРОВАТЬ

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

Answer 1

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

• Поговорите с разработчиком. Обсудите последствия для других членов команды.Большинство разработчиков хотят, чтобы их узнавали среди коллег, поэтому этого может быть достаточно.Также обратите внимание, что гораздо легче исправить ошибки в коде, который свеж в вашей памяти, чем в коде, написанном несколько недель назад.Эта часть имеет смысл, если у вас есть какая-то форма владение кодом на месте.
• Если через некоторое время это не сработает, попробуйте ввести политику, которая сделает фиксацию ошибочного кода неприятной для автора.Один из популярных способов — возложить на человека, сломавшего сборку, ответственность за создание следующей.Если ваш процесс сборки полностью автоматизирован, поищите вместо этого другую черную задачу.Этот подход имеет дополнительное преимущество: он не указывает на кого-то конкретного, что делает его более приемлемым для всех.
• Использовать дисциплинарные меры.В зависимости от размера вашей команды и вашей компании они могут принимать разные формы.
• Уволить разработчика. За хранение плохих яблок приходится платить.Когда вы зайдете так далеко, разработчик не будет заботиться о своих коллегах-разработчиках, и у вас уже возникнут проблемы с людьми.Если рабочая среда станет отравленной, вы можете потерять гораздо больше – с точки зрения производительности и персонала – чем один этот плохой разработчик.

Answer 2

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

Нам требуются проверки перед объединением в ствол итерации, поэтому обычно все улавливается именно тогда.

Answer 3

Ритуальные избиения!За каждого жука — один удар кнутом!

(шутка для тех, кто не понимает)

Answer 4

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

Видимость

Если среда позволяет вытащить код, ожидая, когда пользователи найдут проблемы, а затем по существу спрашивают: «Как насчет сейчас?» После изменения в код, нет реального стимула для проверки ваших собственных вещей.

Анализ кода и сотрудничество побуждают вас работать над созданием качественного продукта гораздо лучше, чем если бы вы просто создавали «Виджет X», пока ваши коллеги работают над «Виджетом Y» и «Виджетом Z».

Чем более заметна ваша работа, тем больше вероятность, что вас будет волновать, насколько хорошо она работает.

Answer 5

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

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

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

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

Answer 6

Сделайте это частью целей своего ежегодного обзора.Если он этого не добьется, зарплата не повысится.

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

Answer 7

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

Answer 8

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

Answer 9

Почему бы просто не поговорить с ним?Скорее всего, он вас не укусит.

Answer 10

• Заставьте его «присматривать» за сборкой и станьте менеджером сборки.Это даст ему меньше времени на разработку кода (таким образом, увеличив производительность каждого) и научит его, почему так необходима хорошая сборка.

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

-Адам

Answer 11

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

Answer 12

Вот несколько идей из морской лачуги.

Intro
   What shall we do with a drunken sailor, (3×)
   Early in the morning?
Chorus
   Wey–hey and up she rises, (3×)
   Early in the morning!
Verses
   Stick him in a bag and beat him senseless, (3×)
   Early in the morning!
   Put him in the longboat till he’s sober, (3×)
   Early in the morning!

и т. д.Замените "пьяного матроса" на "неряшливого застройщика".

Answer 13

В зависимости от типа системы контроля версий, которую вы используете, вы можете настроить политики возврата, которые заставят код соответствовать определенным требованиям, прежде чем ему будет разрешено возвратиться.Если вы используете такую ​​систему, как Team Foundation Server, это дает вам возможность указать требования к покрытию кода и модульному тестированию для регистрации.

Answer 14

Знаете, это прекрасная возможность не выделять его отдельно (хотя я согласен, что вам нужно поговорить с ним) и внедрить процесс «сначала тестирование» внутри компании.Если правила не ясны и ожидания всем известны, я обнаружил, что то, что вы описываете, не так уж и редко.Я считаю, что схема разработки «сначала тестирование» мне подходит и улучшает качество кода.

Answer 15

Они могут быть чрезмерно сосредоточены на скорости, а не на качестве.

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

Чтобы исправить этот баланс:

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

Answer 16

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

1. Под руководством опытного разработчика он узнает, чего от него ждут, и увидит разницу между своим кодом и кодом, который соответствует ожиданиям.
2. Другой разработчик может применить политику сначала тестирования:не разрешать писать код до тех пор, пока для него не будут написаны тесты
3. Аналогично, другой разработчик может проверить, что код соответствует стандартам, прежде чем он будет возвращен, что уменьшит количество плохих возвратов.

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

Answer 17

Кажется, что люди придумали много творческих и коварных ответов на эту проблему.Но дело в том, что это не игра.Разработка сложных систем давления со стороны сверстников, чтобы «назвать и опозорить» его, не поможет добраться до корня проблемы, т.е.почему он не пишет тесты?

Я думаю, тебе следует говорить прямо.Я знаю, ты говоришь, что разговаривал с ним, но ты пытался это выяснить? почему он не пишет тесты?Очевидно, в этот момент он знает, что он должен быть, так что наверняка должна быть какая-то причина, почему он не делает то, что ему сказали делать.Это лень?Прокрастинация?Программисты славятся своим эго и твердым мнением — возможно, он по какой-то причине убежден, что тестирование — пустая трата времени, или что его код всегда идеален и не нуждается в тестировании.Если он незрелый программист, он может не до конца понимать последствия своих действий.Если он «слишком зрелый», возможно, он слишком упрям ​​на своем.Какой бы ни была причина, устраните ее.

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

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

Answer 18

Прикрепите его к его собственной ветке разработки и вносите его вещи в багажник только тогда, когда вы уверены, что они тщательно протестированы.Возможно, именно здесь лучше всего подойдет распределенный инструмент управления исходным кодом, такой как GIT или Mercurial.Хотя благодаря расширенной поддержке ветвления/слияния в SVN у вас может не возникнуть особых проблем с управлением.

РЕДАКТИРОВАТЬ

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

Answer 19

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

Answer 20

Это кажется довольно простым.Сделайте это требованием, и если он не сможет этого сделать, замените его.Зачем тебе его держать?

Answer 21

Обычно я не защищаю это, если все остальное не терпит неудачу...

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

Answer 22

Попробуйте «Морковку», сделайте это веселой игрой.
Например, плагин Continuous Integration Game для Hudson.
http://wiki.hudson-ci.org/display/HUDSON/The+Continious+Integration+Game+plugin

Answer 23

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

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

Answer 24

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

Если он разумный человек, обсудите с ним отчет.

Если он заботится о своей «репутации», регулярно публикуйте отчет и делайте его доступным для всех своих коллег.

Если он слушает только «авторитета», составьте отчет и передайте проблему своему руководителю.

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

Эй, это напоминает мне кое-что я прочитал на xkcd :)

Answer 25

Вы имеете в виду написание автоматического модульного теста или модульное тестирование вручную перед регистрацией?

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

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

Ваш вопрос довольно широк, но я надеюсь, что дал некоторое направление.

Я бы согласился с Филом, что первый шаг — индивидуально поговорить с ним и объяснить важность качества.Низкое качество часто может быть связано с культурой команды, отдела и компании.

Answer 26

Сделайте выполненные тестовые примеры одним из результатов, прежде чем что-то будет считаться «готовым».

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

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

Answer 27

Заставьте человека чистить туалеты.Работал в армии.А если вы работаете в группе с людьми, которые едят много индийской еды, им не понадобится много времени, чтобы встать в очередь.

Но это только я...

Answer 28

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

Answer 29

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

Answer 30

Возможно, здесь вы найдете полезные ответы: Как заставить младших программистов писать тесты?