Отдельные сборки 'debug' и 'release'?

Question

Я думаю, что лучше выпустить версию программного обеспечения, которую на самом деле тестировали ваши разработчики; Поэтому я стремлюсь удалить цель 'debug' из проекта / make-файла, чтобы можно было собрать только одну версию (и протестировать, и отладить, и выпустить).

По той же причине я не использую «утверждения» (см. Также Всегда ли утверждения плохие? ...).

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

Кто-то еще сказал, что "это такая плохая идея"; это политика, которую я выработал несколько лет назад, будучи сожженной:

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

С тех пор я видел, как несколько других цехов разработки следовали этой практике (т.е. не имели отдельных сборок отладки и выпуска).

Какова ваша политика?

Answer 1

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

Всегда использовать утверждения всегда более безопасно, чем никогда их не использовать. При создании отдельных версий отладки и выпуска повторно включите все символы #define d, которые вам нужны, чтобы гарантировать, что утверждения также включены в версии выпуска.

Answer 2

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

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

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

Answer 3

здесь мы разрабатываем в режиме отладки и проводим все юнит-тестирование в режиме выпуска. Мы небольшой магазин с несколькими приложениями (до 12) для поддержки, начиная от Classic ASP, ASP.Net, VB.Net и C #. У нас также есть специальный специалист, отвечающий за все тестирование, отлаженные проблемы возвращаются разработчикам.

Answer 4

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

1) в "сборках релиза" оптимизации отключены (другие разработчики не могут использовать отладчик)

2) Никакие сборки не будут иметь специальных макросов PREPROCESSOR, изменяющих их выполнение.

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

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

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

Answer 5

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

В большинстве средних и крупных проектов простота отладки обеспечит лучший результат для ваших пользователей.

Answer 6

Смотрите это Какое ваше самое противоречивое мнение о программировании?

цитата:

Мнение: никогда не было другого код между «отладкой» и «выпуском» строит

Основная причина этого выпуска код почти никогда не проверяется. Лучше чтобы один и тот же код работал в тесте как это в дикой природе.

Answer 7

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

Хотя по крайней мере в одном случае мы выпустили что-то, что все еще содержало отладочный код. Единственным последствием было то, что он работал чуть медленнее, а файлы журналов были чертовски большими.

Answer 8

В моей компании есть и Debug, и Release. - Разработчики используют отладочную версию, чтобы правильно находить и исправлять ошибки. - Мы используем TDD, и поэтому у нас есть большой набор тестов, который мы запускаем на нашем сервере, который тестирует конфигурации отладки и сборки выпуска, а также сборки 64/32, которые у нас есть.

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

Answer 9

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

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