Ежедневная сборка против нулевого дефекта - PullRequest
14 голосов
/ 03 октября 2008

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

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

Ответы [ 11 ]

0 голосов
/ 03 октября 2008

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

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

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

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

...