Должны ли разработчики работать в песочницах?

Question

Если разработчики выполняют модульное тестирование в своей среде разработки перед проверкой в ​​системе контроля версий, должна ли эта среда (включая неудачи тестирования) быть общедоступной?

Должны ли все сборки быть открытыми?

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

Это просто отвлекает всех.

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

Answer 5

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

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