Как заставить младших программистов писать тесты? [закрыто]

У нас есть младший программист, который просто не пишет достаточно тестов.
Я должен пилить его каждые два часа, "ты написал тесты?"
Мы попробовали:

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

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

Знаете ли вы больше мотивации?

10.08.2008 17:34:46
Наймите меня в своей компании! Я бы с радостью оставил свою ради того, кто достаточно заботился о программном обеспечении, чтобы научить меня, как лучше писать тесты.
Steven Evers 7.08.2009 17:57:23
@SnOrfus - я сменил работу, извините;)
abyx 7.08.2009 19:00:44
Был ли этот код человека хитрым по другим причинам (например, чрезмерно большие классы, непонятные имена переменных) или проблема была только в модульном тестировании?
Andrew Grimm 26.05.2010 03:19:02
@ Андрей, я бы сказал, что все остальное связано с опытом, а тестирование - это скорее мышление?
abyx 27.05.2010 14:55:37
Этот вопрос кажется не по теме, поскольку он не является специфической проблемой программирования и более подходит для разработки программного обеспечения .
hichris123 16.12.2014 22:49:55
24 ОТВЕТА
РЕШЕНИЕ

Это одна из самых сложных вещей . Заставить своих людей получить это .

Иногда одним из лучших способов помочь программистам младшего уровня «получить это» и выучить правильные приемы у старшеклассников является занятие парным программированием.

Попробуйте это: в предстоящем проекте соедините младшего парня с собой или другим старшим программистом. Они должны работать вместе, по очереди «за рулем» (будучи тем, кто печатает на клавиатуре) и «тренируя» (оглядываясь через плечо водителя и указывая на предложения, ошибки и т. Д.). Это может показаться пустой тратой ресурсов, но вы найдете:

  1. То, что эти ребята вместе могут быстро и качественно создавать код.
  2. Если ваш младший парень учится достаточно, чтобы «получить его», а старший парень направит его по правильному пути (например, «Хорошо, теперь, прежде чем мы продолжим, давайте напишем в тесте для этой функции».) Это будет стоить ресурсов, которые вы совершить это.

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

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

123
1.07.2015 14:40:36
Игра в боулинг Ката хороша!
Hertanto Lie 12.12.2008 01:38:44
Ссылка Unit Testing 101 не работает. Я попытался найти архив веб-страницы, но ничего полезного не нашел. Кто-нибудь получил эту презентацию?
displayName 3.09.2015 15:33:04

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

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

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

2
10.08.2008 17:49:22

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

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

Если это так, одна вещь, которую я нашел, - это что-то вроде «неожиданного нового обзора найма». Неважно, если вы никогда не делали этого раньше ... он этого не узнает. Просто сядьте и скажите ему, что вы собираетесь просмотреть его выступление и покажите ему реальные цифры ... возьмите свой обычный лист проверки (у вас есть формальный процесс проверки, верно?) И измените заголовок, если хотите, чтобы он выглядел так чиновник и покажи ему, где он стоит. Если вы покажете ему в очень формальной обстановке, что отсутствие тестов отрицательно влияет на его рейтинг производительности, а не просто "ворчит" ему в этом, он, мы надеемся, поймет это. Вы должны показать ему, что его действия на самом деле повлияют на него, будь то с точки зрения оплаты или нет.

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

4
10.08.2008 17:58:14

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

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

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

12
10.08.2008 18:00:35

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

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

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

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

1
10.08.2008 18:19:17

Вот что я бы сделал:

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

  • После этого ... "Вы закончили? Отлично! Сначала давайте посмотрим на тесты, которые ведут вашу разработку. О, никаких тестов? Дайте мне знать, когда это будет сделано, и мы перенесем просмотр вашего кода. Если вы ' Нужна помощь в формулировании тестов, дайте мне знать, и я помогу вам. "

9
10.08.2008 19:53:27

Проверяйте код перед каждым коммитом (даже если это «1 минута« Я изменил это имя переменной »)», и в рамках проверки кода проверяйте любые модульные тесты.

Не подписывайте коммит, пока тесты не будут на месте.

(Кроме того - если его работа не была проверена - почему она вообще была в рабочей сборке? Если она не проверена, не впускайте ее, тогда вам не придется работать на выходных)

21
11.08.2008 02:45:11

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

Я не знаю, нужно ли вам блокировать такие коммиты. На моем рабочем месте у каждого есть свободный коммит на все, и все SVN коммиты (с diffs) отправляются в команду по электронной почте.

Примечание: вам действительно нужен аддон Thunderbird Colour-Diff, если вы планируете делать это.

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

Вы можете помочь людям привыкнуть к этому, периодически говоря что-то вроде: «Эй, Боб, ты видел этот коммит, который я сделал сегодня утром, я нашел этот хитрый трюк, где ты можешь делать бла-бла, что угодно, читать коммит и видеть как это устроено!"

NB: у нас есть 2 старших разработчика и 3 младших. Это может не масштабироваться, или вам, возможно, придется немного скорректировать процесс с большим количеством разработчиков.

2
11.08.2008 00:35:42

Представьте, что я программист, по имени ... Марко. Представьте, что я закончил школу не так давно, и мне никогда не приходилось писать тесты. Представьте, что я работаю в компании, которая на самом деле не применяет или не просит об этом. ОК? хороший! А теперь представьте, что компания переходит на использование тестов, и они пытаются убедить меня в этом. Я дам несколько странную реакцию на пункты, упомянутые до сих пор, как будто я не проводил никаких исследований по этому вопросу.

Давайте начнем с создателя:

Показано, что дизайн становится проще.

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

Показывая это предотвращает дефекты.

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

Делать это эго, говоря, что только плохие программисты этого не делают.

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

@ Джастин Стандарт : В начале новой перспективы соедините младшего парня с собой или с другим старшим программистом.

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

@ Джастин Стандарт : прочитайте презентацию « Модульное тестирование 101 » Кейт Роудс.

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

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

@ Доминик Куни : Потратьте некоторое время и поделитесь методами тестирования.

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

@ Доминик Куни : отвечать на вопросы, примеры и книги.

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

@ Адам Хейл : Обзор сюрприз.

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

@ Rytmis : элементы считаются выполненными только тогда, когда у них есть тестовые случаи.

Ох, интересно. Я вижу, что действительно должен сделать это сейчас, иначе я ничего не завершаю. Это имеет смысл.

@ Jmorris : Избавиться / Жертвоприношение.

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


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

Рассуждение, подготовка, обучение, сопровождение, поддержка.

16
23.05.2017 11:54:15

Это обязанность его наставника, чтобы научить его / ее. Насколько хорошо вы учите его / ее, как проверить. Вы пара программируете с ним? Младший, скорее всего, не знает, КАК настроить хороший тест для xyz.

Будучи младшим школьником, он знает много концепций. Некоторая техника. Некоторый опыт. Но, в конце концов, весь Юниор ПОТЕНЦИАЛ. Почти каждая функция, над которой они работают, будет что-то новое, чего они никогда не делали раньше. Конечно, младший, возможно, сделал простой шаблон State для проекта в классе, открывая и закрывая «двери», но никогда не применяя шаблоны в реальном мире.

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

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

1
13.08.2008 19:20:30

@ jsmorris

Однажды я заставил старшего разработчика и «архитектора» ругать меня и тестера (это была моя первая работа после окончания колледжа) по электронной почте за то, что я не задержался и не выполнил такую ​​«легкую» задачу накануне вечером. Мы были на этом весь день и объявили, что он уходит в 7 вечера, я бился с 11 утра до обеда в тот день и приставал к каждому члену нашей команды по крайней мере дважды.

Я ответил и сказал команде: «Я был разочарован в тебе уже месяц. Я никогда не получаю помощь от команды. Я буду в кафе через дорогу, если понадоблюсь. Я извините, я не смог отладить метод с 12 параметрами, 800 строк, от которого зависит почти все ».

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

"Значит, ты ушел?"

1
13.08.2008 19:34:12

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

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

Не у всех одинаковый уровень таланта и / или мотивации. Команды разработчиков, даже гибкие, состоят из людей из «A-Team» и из «B-Team». Члены A-Team проектируют решение, пишут весь нетривиальный производственный код и общаются с владельцами бизнеса - всю работу, которая требует нестандартных решений. B-Team управляет такими вещами, как управление конфигурацией, написание сценариев, исправление ошибок и выполнение работ по техническому обслуживанию - вся эта работа имеет строгие процедуры с небольшими последствиями для отказа.

0
22.11.2009 21:42:18

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

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

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

Конечно, я ничего не знаю. Но я надеюсь, что слова были полезны.

Редактировать: [ Джастин Стандарт ]

Не унижайтесь, то, что вы должны сказать, в значительной степени правильно.

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

5
23.05.2017 11:54:15
Я согласен с комментариями выше, но призываю людей быть немного менее формальными с обзорами кода, у меня был обзор кода, когда я был младшим, не зная об этом ранее. Рецензент усадил еще одного разработчика и меня и вынул страницы кода с красным каракулем над ним. Это заставило обоих разработчиков чувствовать себя немного преданными, и мы оба почувствовали, что это было упражнение, чтобы унизить нас. Я бы порекомендовал более неформальные чаты, проходящие по коду, чтобы можно было что-то узнать, а не указывать пальцем.
Burt 24.01.2010 16:04:33
Я полностью согласен, Берт. Обзоры кода должны быть чем угодно, кроме запугивания или унизления. Тем не менее, они все равно должны оставить код улучшенным. Но иметь некоторый код, который работает немного медленнее, ни в коем случае не так вредно, как тратить хорошие деньги на младшего разработчика, который ничего не сделает, потому что боится, что в обзоре им удастся.
Lucas Wilson-Richter 3.02.2010 04:56:45

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

Когда я впервые вышел из универа, я обнаружил, что он сильно меня не устроил, чтобы иметь дело с реальным миром. Да, я знал некоторые основы JAVA и некоторую философию (не спрашивайте), но это было об этом. Когда я впервые получил работу, это было немного сложно, если не сказать больше. Позвольте мне сказать вам, что я, вероятно, был одним из самых больших ковбоев, я бы взломал небольшое исправление ошибки / алгоритм без комментариев / тестирования / документации и отправил бы его за дверь.

Мне посчастливилось быть под присмотром доброго и очень терпеливого старшего программиста. К счастью для меня, он решил сесть со мной и провести 1-2 недели, просматривая мой очень взломанный код togethor. Он объяснил бы, где я ошибся, более тонкие точки c и указатели (мальчик сделал это, смутило меня!). Нам удалось написать довольно приличный класс / модуль примерно за неделю. Все, что я могу сказать, это то, что если бы старший разработчик не потратил время, чтобы помочь мне на правильном пути, я бы, вероятно, не продержался бы очень долго.

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

Забрать домой очки

  1. Большинство университетов очень плохо готовят студентов к реальному миру
  2. Парное программирование действительно помогло мне. Это не значит, что это поможет всем, но это сработало для меня.
3
18.08.2008 19:42:34

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

0
18.08.2008 20:12:24

Для себя я начал настаивать на том, чтобы каждая найденная и исправленная ошибка выражалась в виде теста:

  1. "Хм, это не правильно ..."
  2. Найти возможную проблему
  3. Написать тест, показать, что код не работает
  4. Решить проблему
  5. Покажите, что новый код проходит
  6. Цикл, если исходная проблема сохраняется

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

(Я не живу в среде коммерческого программирования и часто являюсь единственным программистом, работающим над конкретным проектом.)

20
22.08.2008 17:50:21
+1 Я думаю, что это отличный способ начать тестирование. Таким образом, известные ошибки никогда не появятся случайно.
Jonathan 8.04.2009 09:00:46
Это называется регрессионное тестирование! :)
pfctdayelise 13.10.2009 12:33:50

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

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

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

0
27.08.2008 03:52:11
  1. Сделать охват кода частью обзоров.
  2. Сделайте «написать тест, который разоблачает ошибку», как предварительное условие для исправления ошибки.
  3. Требовать определенного уровня покрытия, прежде чем код может быть зарегистрирован.
  4. Найдите хорошую книгу по разработке через тестирование и используйте ее, чтобы показать, как тестирование в первую очередь может ускорить разработку.
2
29.08.2008 18:55:24

В вашем исходном репозитории: используйте ловушки перед каждым коммитом (например, ловушка перед фиксацией для SVN)

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

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

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

Разработчик должен иметь возможность проверить, покрывает ли его контрольные примеры 100% кода. Таким образом, если он не передает проверенный на 100% код, это его собственная ошибка, а не ошибка «упс, извините, я забыл».

Помните: люди никогда не делают то, что вы ожидаете, они всегда делают то, что вы проверяете.

1
29.08.2008 19:19:31

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

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

3
18.09.2008 01:05:51

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

Вы можете сформулировать это в любых терминах, которые вы считаете подходящими, резкими или мягкими, это не имеет значения. Но дело в том, что программистам не платят за то, что они просто собирают код и регистрируют его - им платят за то, чтобы тщательно собрать код, затем собрать тесты, затем протестировать их код, ТОГДА проверить все. (По крайней мере, вот как это звучит, из вашего описания.)

Следовательно, если кто-то собирается отказаться выполнять свою работу, объясните ему, что он может остаться дома завтра, и вы наймете того, кто БУДЕТ выполнять эту работу.

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

Удачи.

2
7.11.2008 07:13:08

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

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

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

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

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

Немного менее мстительный подход позволил бы этому человеку делать то, что у него получается хорошо (я предполагаю, что этот человек был нанят, потому что он действительно компетентен в программировании), и нанял бы одного или двух тестировщиков для тестирования ( У студентов университетов часто бывают практические или «кооперативные» термины, им понравится экспозиция, и они дешевы)

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

Если ваша организация меньше 6 или вам не удается создать новую команду, я рекомендую парное программирование (PP). Я не являюсь полным сторонником всех экстремальных методов программирования, но я определенно верю в парное программирование. Однако оба члена команды парного программирования должны быть преданы делу, иначе это просто не сработает. Они должны следовать двум правилам: инспектор должен полностью понимать, что кодируется на экране, или он должен попросить кодировщика объяснить это; кодер может кодировать только то, что он может объяснить - никакие «вы не увидите», «не доверяете мне» или махание рукой не допустимы.

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

Если PP не для вас, то TDD - ваш лучший выбор, но только если его воспринимать буквально. Разработка через тестирование означает, что вы сначала пишете тесты, запускаете тесты, чтобы доказать, что они действительно проваливаются, а затем пишете простейший код, чтобы он работал. Компромисс теперь в том, что у вас (должно быть) есть коллекция из тысяч тестов, которые также являются кодом, и с той же вероятностью, что и рабочий код, содержит ошибки. Честно говоря, я не большой поклонник TDD, в основном по этой причине, но он работает для многих разработчиков, которые предпочитают писать тестовые сценарии, а не документы тестовых примеров - некоторые тесты лучше, чем ничего. Соедините TDD с PP для большей вероятности покрытия тестами и уменьшения количества ошибок в сценарии.

Если все остальное терпит неудачу, имейте эквивалентность ругательства для программистов - каждый раз, когда программист ломает сборку, они должны положить 20, 50, 100 долларов (что бы ни было умеренно болезненно для вашего персонала) в банку, которая достанется вашему любимому ( зарегистрирован!) благотворительность. Пока они не заплатят, избегайте их :)

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

1
7.11.2008 08:58:15

Он уже делает это. В самом деле. Он просто не записывает это. Не убежден? Посмотрите, как он проходит стандартный цикл разработки:

  • Напишите кусок кода
  • Скомпилируйте это
  • Беги, чтобы увидеть, что он делает
  • Напишите следующий кусок кода

Шаг № 3 - это тест. Он уже проводит тестирование, он просто делает это вручную. Задайте ему вопрос: «Как вы узнаете завтра, что код от сегодняшнего дня все еще работает?» Он ответит: «Это так мало кода!»

Спросите: «Как насчет следующей недели?»

Когда у него нет ответа, спросите: «Как бы вы хотели, чтобы ваша программа сообщала вам, когда изменение нарушает то, что сработало вчера?»

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

5
24.02.2009 14:25:49

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

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

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

2
24.02.2009 14:35:34