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

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

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

Это простая политика, которая дает лучшее из обоих миров, ИМО.

Edit: в ответ на комментарий Я думаю, что очевидно, что сборки debug и release (могут) генерировать другой код. Подумайте" - DDEBUG "против" - DNDEBUG "и" #if defined(DEBUG) " и т. д.

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

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

Как удалить двоичные файлы и загрузить символы в отладчике из внешнего источника зависит от платформы.

наша политика заключается в том, чтобы разработчики работали над отладочными сборками, но все остальные (QA, BAs, sales и т. д.) запускают версию выпуска. Вчера мне пришлось исправить ошибку, которая появилась только в выпуске build it, было очевидно, что происходит просто потому, что она появилась только в выпуске

Это первый здесь, в этом магазине, и я здесь 18 месяцев или около того.

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

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

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

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

часть, где вы пошли не так, это утверждение:

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

разработчики не тестируют код. Тест код.

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

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

согласно моему ответу в связанном потоке, мы также используем ту же сборку для отладки и выпуска по очень похожим причинам. 10% -20% прироста производительности от оптимизатора, как правило, очень незначительны по сравнению с ручными оптимизациями на уровне алгоритма. Одна сборка удаляет много потенциальных ошибок. В частности;

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

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

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

при разработке С Java я ненавижу версии без отладки. Когда возникает исключение, вы не получаете никакой информации о строке,что затрудняет или даже невозможно отслеживать ошибки. Кроме того, разница во времени выполнения между debug и non-debug составляет около 5% С Java 5 или более поздней версии, поэтому это действительно не проблема, и с сегодняшними жесткими дисками размер больше не имеет значения.

с другой стороны, используя отладочные версии:

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

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

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

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

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

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

на мой взгляд, в этом обсуждении отсутствует очень важный момент:

Это действительно зависит от того, какой проект!

Если вы создадите собственный проект (C / C++), вы фактически будете вынуждены создавать сборки отладки, просто потому, что оптимизация компилятора может сделать отладку почти невозможной в некоторых случаях.

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

хотя родной проект C++ и веб-приложение PHP, очевидно, не все виды проектов, которые существуют, я надеюсь, что моя точка зрения получила.

P.S.: При разработке для C# вы сталкиваетесь с пограничным случаем, поскольку, хотя использование отладочной сборки отключает оптимизацию компилятора, по моему опыту, вы не столкнетесь с почти такими же различиями, как с C++

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

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

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

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

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

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

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

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

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

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

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

Так что вы действительно делаете слияние выпуска и конфигурации debug, а не устранение только режима "отладки".

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

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

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

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

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

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

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

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

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

цитата:

мнение: никогда не бывает по-другому код между "debug" и " release" строит

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