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

23
задан 16 revs, 7 users 57% 14 January 2010 в 14:02
поделиться

44 ответа

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

  • Говорят с разработчиком. Обсуждают последствия для других в команде. Большинство разработчиков хочет быть распознанным их коллегой, таким образом, это могло бы быть достаточно. Также укажите, что намного легче исправить ошибки в коде, это ново в Вашем уме, чем код недельной давности. Эта часть имеет смысл, если у Вас есть некоторая форма owneship кода на месте.
  • , Если это не работает через какое-то время, попытайтесь поместить на месте политику, которая сделает фиксирующий содержащий ошибки код неприятным для автора. Один популярный путь состоит в том, чтобы сделать человека, который повредил сборку, ответственную за работу по дому создания следующего. Если Ваш процесс сборки полностью автоматизирован, ищите другую черную задачу заботиться о вместо этого. Этот подход обладает дополнительным преимуществом не точного определения любого, в частности, делая его более приемлемым для всех.
  • дисциплинарные меры Использования . В зависимости от размера Вашей команды и Вашей компании, те могут принять много форм.
  • Огонь разработчик. существует стоимость, связанная с хранением плохих яблок. Когда Вы добираетесь настолько далеко, разработчик не заботится о своих поддерживающих разработчиках, и у Вас уже есть люди проблема на Ваших руках. Если рабочая среда становится отравленной, Вы могли бы проиграть намного более - мудрый производительностью и мудрый людьми - чем этот единственный плохой разработчик.
32
ответ дан 3 revs, 2 users 92% 29 November 2019 в 00:33
поделиться

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

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

21
ответ дан Ross Anderson 19 July 2019 в 20:11
поделиться

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

1
ответ дан Tons0fun 29 November 2019 в 00:33
поделиться

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

1
ответ дан Carra 29 November 2019 в 00:33
поделиться

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

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

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

1
ответ дан JohnMcG 29 November 2019 в 00:33
поделиться

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

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

1
ответ дан D.S. 29 November 2019 в 00:33
поделиться

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

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!

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

7
ответ дан Rafał Dowgird 29 November 2019 в 00:33
поделиться

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

Видимость

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

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

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

14
ответ дан Kevin Fairchild 29 November 2019 в 00:33
поделиться

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

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

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

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

10
ответ дан Nick Sergeant 29 November 2019 в 00:33
поделиться

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

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

10
ответ дан 2 revs 29 November 2019 в 00:33
поделиться

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

9
ответ дан Paul Dixon 29 November 2019 в 00:33
поделиться

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

9
ответ дан RossFabricant 29 November 2019 в 00:33
поделиться

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

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

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

-Adam

8
ответ дан Adam Davis 29 November 2019 в 00:33
поделиться

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

7
ответ дан Paul Whelan 29 November 2019 в 00:33
поделиться

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

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

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

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

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

1
ответ дан Mark Lindell 29 November 2019 в 00:33
поделиться

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

5
ответ дан Micah 29 November 2019 в 00:33
поделиться

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

5
ответ дан itsmatt 29 November 2019 в 00:33
поделиться

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

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

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

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

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

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

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

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

3
ответ дан Simon Howard 29 November 2019 в 00:33
поделиться

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

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

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

2
ответ дан Kibbee 29 November 2019 в 00:33
поделиться

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

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

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

3
ответ дан Crippledsmurf 29 November 2019 в 00:33
поделиться

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

2
ответ дан lillq 29 November 2019 в 00:33
поделиться

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

2
ответ дан bruceatk 29 November 2019 в 00:33
поделиться

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

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

2
ответ дан Joe Strazzere 29 November 2019 в 00:33
поделиться

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

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

1
ответ дан danivovich 29 November 2019 в 00:33
поделиться

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

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

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

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

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

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

1
ответ дан Remo.D 29 November 2019 в 00:33
поделиться

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

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

42
ответ дан Ian P 29 November 2019 в 00:33
поделиться

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

0
ответ дан Josh Wright 29 November 2019 в 00:33
поделиться

Протестируйте свое написание! Я думаю, что Вы имели в виду "их код".

  • Говорят с ним. Сообщите ему, это - проблема.
  • Имеют группу, встречающуюся для обсуждения качества кода.
  • , Если это все еще плохо, вынудите его проверить свой код, прежде чем он сможет регистрировать его.
  • , Если он не получает подсказку к тому времени, необходимо будет позволить ему пойти.
0
ответ дан Oli 29 November 2019 в 00:33
поделиться
Другие вопросы по тегам:

Похожие вопросы: