Можно ли иметь одну конфигурацию вместо разделения Debug и Release (в нашем случае)?

Question

Мы разрабатываем продукт для внутренних клиентов. У нас нет команды QA, и мы не используем утверждений. Производительность важна, размер приложения - нет.

Является ли хорошей идеей иметь одну конфигурацию (вместо разделения Debug и Release), которая будет иметь отладочную информацию (pdbs), а также оптимизировать производительность?

Есть ли минусы в этом подходе?

Answer 1

Держите оба. Есть причина иметь две конфигурации! Используйте Debug для отладки и Release для повседневного использования.

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

Answer 2

Я бы сказал, что вы всегда должны хранить версии отладки и выпуска отдельно.Релизные версии для ваших клиентов, отладочные версии для ваших разработчиков.Вы говорите, что не пользуетесь утверждениями: возможно, так и должно быть?Даже если вы не используете утверждения в своем собственном коде, вы все равно можете запускать утверждения в базовом коде библиотеки, например, при использовании недопустимых итераторов.Это даст разработчику предупреждение о том, что что-то не так.Что бы сделал пользователь, если бы увидел это сообщение: паника, позвонить в техподдержку, ничего не делать?

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

Answer 3

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

Производительность готового продукта, таким образом, в значительной степени требует, чтобы он был «релизной» версией, а не отладочной версией и, конечно, не каким-то странным сочетанием этих двух.

Answer 4

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

Answer 5

Это нормально иметь один конфигурация, а не разделение Отладка и выпуск (в нашем случае)?

Это может быть хорошо - это сильно зависит от вашего случая (но в зависимости от ваших данных, я думаю, что это очень не ОК).

У нас нет команды QA и мы не используем утверждений.

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

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

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

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

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

Мне кажется, что у вас действительно есть команда QA, вы просто не видите ее так: ваши внутренние клиенты (которые могут даже быть вами) - ваша команда QA . Это плохая идея, в той степени, в которой важна функция вашего приложения.

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

Производительность важна, размер приложения - нет.

Если важна производительность, кто ее измеряет? Код измерения принадлежит вашему опубликованному приложению? Вы добавляете это и удаляете это в выпущенном коде?

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

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

Есть ли минусы в этом подходе?

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

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

Answer 6

У тебя должно быть как минимум два.Один для релиза (производительности) и один для отладки - или вы пишете идеальный код, впервые каждый раз?