Один из наших разработчиков постоянно пишет код и помещает его в контроль версий без его тестирования. В результате пострадает качество нашего кода.
Помимо избавления от разработчика, как я могу решить эту проблему?
ИЗМЕНИТЬ
Я говорил с ним об этом несколько раз и даже дал ему письменное предупреждение
Если вы систематически выполняете обзоры кода, прежде чем позволить разработчику совершить код, ну, ваша проблема в основном решена. Но это не похоже на ваш случай, поэтому я рекомендую:
Если вы можете делать обзоры кода - это идеальное место, чтобы поймать его.
Мы требуем обзоров до слияния с итерационной магистралью, поэтому обычно все поймано.
(Шутка для тех, кто этого не понимает)
Как разработчик, который редко тестирует свой собственный код, я могу сказать вам одно, что заставило меня медленно сдвинуть мое поведение...
Видимость
Если среда позволяет выталкивать код, ожидая, что пользователи найдут проблемы, а затем, по существу, спросят: "Как насчет сейчас?" после внесения изменений в код, нет никаких реальных стимулов для проверки ваших собственных вещей.
Кодовые обзоры и сотрудничество побуждают вас работать над тем, чтобы сделать качественный продукт намного больше, чем если бы вы просто доставляли "Виджет X", а ваши коллеги работали над "Widget Y" и "Widget Z"
Чем более заметна ваша работа, тем более вероятно, что вам нужно заботиться о том, как хорошо она работает.
Сделайте его частью его целей Годового обзора. Если он этого не достигнет, повышение зарплаты не будет.
Иногда, хотя вам просто нужно признать, что кто-то просто не подходит для вашей команды/среды, он должен быть последним средством и может быть трудно справиться, но если вы исчерпали все другие варианты, это может быть лучше всего в долгое время.
Сообщите разработчику, что вы хотели бы увидеть изменения в своей практике в течение 2 недель, или вы начнете дисциплинарную процедуру своей компании. Предлагайте как можно больше помощи и помощи, но если вы не можете изменить этого человека, он не подходит для вашей компании.
Используя Cruise Control или аналогичный инструмент, вы можете заставить проверки автоматически запускать сборку и модульные тесты. Вам все равно нужно будет убедиться, что есть единичные тесты для любых новых функций, которые он добавляет, что вы можете сделать, посмотрев на свои проверки. Тем не менее, это человеческая проблема, поэтому техническое решение может идти только до сих пор.
Обзор кода. Придерживайтесь всех своих разработчиков в комнате каждый понедельник утром и попросите их принести их самое гордое выполнение на основе кода с предыдущей недели вместе с ними на встречу.
Пусть они заглядывают в глаза и волнуются, объясняя, что они сделали. Попросите их принести копии кода, чтобы другие разработчики могли видеть, о чем они говорят.
Мы начали этот процесс несколько месяцев назад, и это удивительно, чтобы увидеть количество подсознательных проверок качества, которые имеют место. В конце концов, если разработчикам просто попросят поговорить о том, что их больше всего волнует, они будут полностью готовы, чтобы показать людям свой код. Затем другие разработчики будут видеть ошибки качества и публично обсуждать, почему они ошибаются и как код действительно должен быть написан.
Если это не поможет вашему разработчику написать качественный код, он, вероятно, не подходит для вашей команды.
Почему бы просто не поговорить с ним? Вероятно, он вас не укусит.
Сделайте его "babysit" сборкой и станьте менеджером сборки. Это даст ему меньше времени для разработки кода (тем самым увеличивая производительность каждого) и научит его, почему такая хорошая сборка настолько необходима.
Принудительные тестовые примеры - код не может быть отправлен без unit test. Измените систему сборки так, чтобы, если тестовые примеры не компилируются и не выполняются правильно или не существуют, тогда вся проверка задачи запрещается.
-Adam
Опубликовать статистику по охвату тестового кода для каждого разработчика, это было бы после разговора с ним.
Вот некоторые идеи из морской лачуги.
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!
и т.д.. Замените "пьяного матроса" "небрежным разработчиком".
В зависимости от типа системы управления версиями, которую вы используете, вы можете настроить политики регистрации, которые вынуждают код передавать определенные требования, прежде чем им разрешат регистрация. Если вы используете систему, такую как Team Foundation Server, она дает вам возможность определять требования к кодовому покрытию и модулю тестирования для регистрации.
Вы знаете, это прекрасная возможность не выделять его (хотя я согласен, что вам нужно поговорить с ним), и внедрить первый тестовый процесс внутри компании. Если правила не ясны и ожидания известны всем, я обнаружил, что то, что вы описываете, не так уж и необычно. Я считаю, что выполнение первой схемы разработки хорошо работает для меня и улучшает качество кода.
Они могут быть чрезмерно сосредоточены на скорости, а не на качестве.
Это может побудить некоторых людей броситься через проблемы, чтобы очистить их список и посмотреть, что возвращается в отчетах об ошибках позже.
Чтобы исправить этот баланс:
Одноранговое программирование - еще одна возможность. Если он с другим опытным разработчиком в команде, который умирает, отвечают стандартам качества и знает процедуру, то у этого есть несколько преимуществ:
Все это, конечно, требует от компании и разработчиков восприимчивости к этому процессу, которого они не могут быть.
Кажется, что люди придумали много изобретательных и хитрых ответов на эту проблему. Но дело в том, что это не игра. Разработать сложные системы давления сверстников, чтобы "назвать и позорить", он не достигнет корня проблемы, т.е. почему он не пишет тесты?
Я думаю, ты должен быть прямым. Я знаю, вы говорите, что говорили с ним, но пытались ли вы выяснить, почему он не пишет тесты? Ясно, что в этот момент он знает, что он должен быть, поэтому наверняка должна быть какая-то причина, почему он не делает то, что ему сказали. Это лень? Прокрастинация? Программисты славятся своими эго и сильными мнениями - возможно, он почему-то убедил, что тестирование - пустая трата времени или что его код всегда идеален и не нуждается в тестировании. Если он незрелый программист, он может не полностью понять последствия своих действий. Если он "слишком зрелый", он может быть слишком настроен. Какова бы ни была причина, обратитесь к нему.
Если дело доходит до мнения, вам нужно заставить его понять, что ему нужно отложить свое личное мнение и просто следовать правилам. Дайте понять, что если ему не доверяют следовать правилам, он будет заменен. Если он все еще не делает этого, сделайте именно это.
Последнее - документируйте все ваши обсуждения вместе с любыми проблемами, возникающими в результате его изменений. Если дело доходит до худшего, вы можете быть вынуждены оправдать свои решения, и в этом случае наличие документальных свидетельств несомненно будет бесценным.
Придерживайте его в своей собственной ветки развития и только приносите его вещи в багажник, когда вы знаете, что это тщательно проверено. Это может быть место, где превосходный инструмент управления распределенным источником, например GIT или Mercurial. Хотя с расширенной поддержкой ветвления/слияния в SVN, у вас может не быть слишком много проблем с ее управлением.
ИЗМЕНИТЬ
Это только если вы не можете избавиться от него или заставить его изменить свои пути. Если вы просто не можете остановить это поведение (путем изменения или стрельбы), то лучшее, что вы можете сделать, - это избавить остальную часть команды от плохих последствий его кодирования.
Если вы находитесь в месте, где вы можете повлиять на политику, внесите некоторые изменения. Проводите проверку кода перед проверкой и выполняйте тестирование части цикла разработки.
Кажется довольно простым. Сделайте это требование, и если он не сможет этого сделать, замените его. Зачем ты его держишь?
Я обычно не защищаю это, если все остальное не срабатывает...
Иногда публично отображаемая диаграмма подсчета ошибок может проявлять достаточное давление со стороны сверстников, чтобы получить благоприятные результаты.
Попробуй Морковь, сделай это забавной игрой.
Например, плагин Continuous Integration Game для Hudson
http://wiki.hudson-ci.org/display/HUDSON/The+Continuous+Integration+Game+plugin
Поместите своих разработчиков в ветки вашего кода, основываясь на некоторой логике, например, на каждую функцию, на исправление ошибок, для каждой команды разработчиков, что угодно. Затем плохие проверки изолированы от этих ветвей. Когда придет время сделать сборку, слияние с веткой тестирования, найти проблемы, решить, а затем объединить выпуск обратно в основную ветвь.
Или удалите права фиксации для этого разработчика и попросите их отправить свой код младшему разработчику для проверки и тестирования, прежде чем его можно будет совершить. Это может мотивировать изменение процедуры.
Вы можете собрать отчет с ошибками, найденными в коде, с именем программиста, ответственного за эту часть программного обеспечения.
Если он разумный человек, обсудите с ним отчет.
Если он заботится о своей "репутации", регулярно публикуйте отчет и предоставляйте его всем своим сверстникам.
Если он только слушает "авторитет", делайте отчет и эскалируйте проблему своему менеджеру.
Во всяком случае, я часто видел, что, когда люди осознают, насколько плохи они кажутся извне, они меняют свое поведение.
Эй, это напоминает мне что-то, что я читал на xkcd:)
Вы имеете в виду автоматическую запись unit test или ручное модульное тестирование перед регистрацией?
Если ваш магазин не пишет автоматические тесты, то его проверка кода, которая не работает, безрассудно. Это влияет на команду? У вас есть формализованный отдел QA?
Если вы все создаете автоматические модульные тесты, я бы предположил, что часть процесса проверки кода также включает в себя модульные тесты. Становится очевидным, что код не подходит для ваших стандартов во время вашего обзора.
Ваш вопрос довольно широк, но я надеюсь, что я дал какое-то направление.
Я согласен с Филом, что первым шагом будет индивидуальный разговор с ним и объяснение важности качества. Плохое качество часто может быть связано с культурой команды, отдела и компании.
Сделайте выполненные тестовые примеры одним из результатов, прежде чем что-то считается выполненным.
Если вы не выполнили тестовые примеры, то работа не завершена, и если крайний срок проходит до того, как вы задокументировали выполнение тестового примера, то он не выполнил вовремя, и последствия будут такими же, как и если он не завершил разработку.
Если культура вашей компании не позволит этого, и она ценит скорость над точностью, то это, вероятно, корень проблемы, а разработчик просто реагирует на стимулы, которые есть на месте - он вознаграждается за то, что делает много вещей, а не меньше, чем правильно.
Сделайте уборщика уборщиком. Работал в армии. И если вы работаете в группе с людьми, которые едят много индийской пищи, они не займут много времени, чтобы они упали в линию.
Но это только я...
Каждый раз, когда разработчик проверяет что-то, что не компилируется, поместите деньги в банку. Вы подумаете дважды, прежде чем регистрироваться.
К сожалению, если вы уже много раз говорили с ним и давали ему письменные предупреждения, я бы сказал, что пришло время его исключить из команды.
Здесь вы можете найти полезные ответы: Как заставить младших программистов писать тесты?