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

Ритуальные избиения! Для каждой ошибки, одного удара плетью кнута!

(Шутка для любого, кто не получает его)

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

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

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

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

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

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

, Но это - просто я...

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

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!

и т.д. Замена "пьяный моряк" с "неаккуратным разработчиком".

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

Видимость

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

обзоры Кода и сотрудничество поощряют Вас работать для создания качественного продукта намного больше, чем если бы Вы просто поставляли 'Виджет X', в то время как Ваши коллеги работают над 'Виджетом Y' и 'Виджетом Z'

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

Обзор кода. Засуньте весь свой dev's в комнате каждый понедельник утром и попросите, чтобы они принесли свое самое гордое основанное на коде выполнение с предыдущей недели наряду с ними на встречу.

Позволяют им взять центр внимания и прийти в восторг от объяснения, что они сделали. Сделайте, чтобы они принесли копии кода, таким образом, другой dev's видит то, о чем они говорят.

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

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

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

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

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

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

Почему не просто говорят с ним? Он, вероятно, на самом деле не укусит Вас.

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

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

-Adam

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

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

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

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

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

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

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

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

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

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

Для исправления этого баланса:

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

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

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

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

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

Прикрепите его на его собственное ответвление разработки, и только принесите его материал в соединительную линию, когда Вы знаете, что это полностью тестируется. Это могло бы быть местом, где распределенный инструмент управления управления исходным кодом как МЕРЗАВЕЦ или Подвижный выделится. Хотя с увеличенной переходящей/объединяющей поддержкой в SVN, Вы не могли бы испытать слишком много затруднений при управлении им.

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

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

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

1. С опытным разработчиком через его плечо он изучит то, что ожидается его, и посмотрите различие между его кодом и кодом, который оправдывает надежды
2. , другой разработчик может осуществить тест первая политика: не разрешение кода быть записанным до тестов было записано для него
3. Точно так же, другой разработчик может проверить, что код до стандарта, прежде чем в этом зарегистрируются reduicing nmber плохих регистраций

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

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

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

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

Иногда, публично отображенная диаграмма bug-count-by-developer может применить достаточно давления со стороны окружающих для получения благоприятных результатов.

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

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

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

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

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

, Если он только слушает "полномочия", сделайте отчет и нарастите проблему его менеджеру.

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

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

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

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

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

1. это какие-либо тесты или комплексные испытания? Некоторые могут кодировать вслепую и действительно обнуляют тесты, но это довольно редко, IME. Обычно существуют некоторые сделанные тесты, но недостаточно покрывать большинство чехлов, которые были бы комплексным тестированием.

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

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

4. вопрос о политике Регистрации. Некоторые места, такие как мое текущее рабочее место, поощряют фиксировать часто, который может означать, что каждый действительно фиксирует код без тестов. Существует ли известная, принятая и хорошо сопровождаемая политика, где вы? Это - другой аспект здесь.

Попробуйте моркови, сделайте ее веселой игрой Отказ
E.G Плагин игры с непрерывной интеграцией для HUDSON
http://wiki.hudson-ci.org/display/hudson/the+Connousured Ginsegration+Game+Plugin