у нас есть один молодой программист, который суперски программит, нообсалютно не хочет подчинятся процессу разработки ПО :)
Ставит версии багов на абум, статусы захочет поставит fixed, захочет won't fix, причём комменты тоже никак не относятся к тому что он сделал и к статусу. Его баги тестить это как крассворды разгадывать.
Начинаеш ему что то втирать он весь краснеет и начинает арать что это не его fault, как будто вообще его кто то обвиняет, просто просят делать как все в будущем. Я боюсь на него наежать так как ещё сматается в другую компанию а менеджер меня потом прибьёт. Но уже задрало. Что с ним делать?

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

Ты должна не ему "втирать", а менеджеру. Это ж не программист, а хакер.

и как показывает практика, такие программисты как правило производят ужасный код, несмотря на свою крутость

Что с ним делать?
------
А ничего с ним не делать.
Есть изменение статуса бага - надо тестить. Т.е. нормальным образом получать квоту времени на выполнение работы по тестированию (перетестированию) и эту работу делать.
Репорт об состоянии - обратно.
Остальным будет заниматься менеджер.
Начинаеш ему что то втирать ...
начинает арать что это не его fault
-----
Ну и не втирай. Результаты теста в репорт и забыть. Для втирания есть менеджер.
Его баги тестить это как крассворды разгадывать.
------
А причем здесь "его баги"? Тестируется то что и как должно работать. Т.е. - на соответствие тех.заданию. Кто и как писал код - знать при этом вредно, об коментах в баг-репорте - подавно.
Но уже задрало.
-----
Бракуй код по-чаще. По любому несоответствию заданию.

Интересно, в чем крутость заключается ;)

забыл кавычки поставить :-)
иногда бывает, что человек быстро выдает на гора работающий код, но если туда заглянуть, то очень часто это какие-то неподдерживаемые спагетти, слепленные кое-как, чтобы работало. такой код очень тяжело сопровождать, и часто бывает быстрее выкинуть и написать в модульном стиле...
P.S. 2Kislosladkaya: у этого "программиста" поди еще и unit-тестов нету?

Да, мне это знакомо.
зы У нас тестов тоже почти нет, потому что легаси. Черт бы его побрал.

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

не путай юнит тесты, с другими видами тестирования. юнит-тесты - задача программиста, задача тестера - smoke tests, integration tests и т.д.

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

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

никак не спорно. читай http://en.wikipedia.org/wiki/Software_testing#Testing_Levels и http://en.wikipedia.org/wiki/Unit_testing
тестировщики обычно не имеют доступа к исходному коду, да и в первую очередь юнит-тесты предназначены для контроля базовой функциональности, базовых функций и т.д. Вот Integration testing - это уже смешанная работа

тестировщики обычно не имеют доступа к исходному коду
-----
Я и говорю - желательно разделять.
да и в первую очередь юнит-тесты предназначены для контроля базовой функциональности, базовых функций и т.д.
------
Или у меня задачи более-мение нестандартные, или организация работ хромает - этого уровень тестирования лежит на мне, но без разработки специальных тестов. Знаю, что есть NUnit, но необходимость писать тесты съедает время, которое с большей результативностью тратится на отладку следующего уровня.
Не факт, что это правильно, но для меня - так. Вероятно сказывается работа на чистом Си с разнесением переменных по модулям - опыт достаточного внимания к деталям.
Вот Integration testing - это уже смешанная работа
-----
С этого и начинается. Только, опять таки, программист этим заниматься не должен. Спецификация и вперед тестер - готовься к приему черного ящика. Оттестить, внятным языком разъяснить что не работает и на следующий круг...

Видимо, в их с(т)ране этому не учили ;)

Если писать хеловорлды то да.
Или ты пишешь безбажный код ?

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

по моему опыту, наличие юнит-тестов на основные вещи, резко снижает необходимость в дальнейшей отладке - ты определяешь баги раньше, чем они будут воздействовать на другие подсистемы. И это не только мое наблюдение - почитай книги по управлению процессами разработки, во всех написано, что обнаружение бага должно происходить как можно ближе к процессу когда баг был внесен, иначе затраты возрастают многократно. Юнит-тесты - идеальный инструмент для этого
P.S. у нас в багзилле есть отдельные поля - где баг был внесен, и где он был обнаружен. на основании этой информации затем делаются выводы о необходимости улучшения процесса разработки
P.P.S. про себя могу сказать, что у меня покрытие кода тестами на уровне 80% (не покрыты в основном участки типа Bla-Bla *a = new bla-bla; if (!a) {report error}. И это играет мне на руку - в предверии релиза на мне не висит ни одной баги, в отличии от разработчиков, которые тесты не используют - у них по 30-40 багов на человека

На уровне code review это у вас не прописано?

ты определяешь баги раньше, чем
-----
Ты не покажешь образец своего кода и соответствующие тесты? Желательно,
не самые тривиальные.
Вот моя ситуация с багами на последнем месте работы.
Происходит миграция с версии на версию. В результате миграции система
должна производить тот выход, что и в первой версии.
Одна из новинок - динамическое отслеживание навигации по объектам.
В первой версии (база) - отсутствовала, (таблица) - константа, (поле) - поле.
Т.е. пишем:
1) база.таблица1.поле
2) база.таблица2.поле
и имеем в свойствах поля именно то, что определено для конкретного
поля. Наборы свойств для 1) и 2) разные и частично определяют выход.
Система в целом - работает - т.е. нет необработанных прерываний
и процесс доходит до завершения.
Выход - тоже генерируется. По большей части - правильно. Но время
от времени - неправильно. Когда происходит сбой - непонятно - одни
и те же исходные данные приводят к обоим - правильному и неправильному
результатам.
Если брать тер. базис, то выход определяется перемножением двух языков
(читай - двух бесконечостей). Собственно, миграция на новую версию и
была процессом введения второго языка. Грамматики обоих языков определены
не полностью. Доопределить - не удается принципиально - система "открытая"
для языков.
Багов в системе было несколько - от архитектурных - не различались идентификаторы
объектов - в первой версии с этой проблемы не было вообще и задача различения
не ставилась, до неправильно определения контекста... но как-то с этим справился.
Написать полные тесты для подобной системы элементарно невозможно - пара
бесконечностей мешает.
Частичные - не выявляют всех проблем.
По-элементные или юнит тесты - не дают никаких ошибок - все элементы
отрабатывают как планировалось.
Я не говорю, что тесты - лишнее. Просто не всегда и не везде затраты на написание
тестов будут релевантны.
во всех написано, что обнаружение бага должно происходить как можно ближе
к процессу когда баг был внесен, иначе затраты возрастают многократно.
-----
Так это все понятно. Чем быстрее быстрее обнаружишь где спорол фигню, тем
меньше править. Мелкомягкие, правда, привыкли объявлять баги фичами, но это
не мое...