Что-то не так с выпуском программного обеспечения в режиме отладки?

Question

Мы все знаем, что «Режим отладки» следует использовать для разработки, потому что компилятор производит больше информации об отладке, а «Режим выпуска» следует использовать для производственных выпусков, потому что компилятор создает оптимизированный код.

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

Есть ли еще веские причины для выпуска программного обеспечения в режиме выпуска в этом случае?

Answer 1

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

1) Компиляция страниц ASP.NET занимает больше времени (поскольку некоторые пакетные оптимизации отключены)

2) Код может выполняться медленнее (поскольку некоторые дополнительные пути отладки включены)

3) Гораздо больше памяти используется приложением во время выполнения

4) Скрипты и изображения, загруженные из обработчика WebResources.axd, не кэшируются

Последний пункт - это просто убийца для определенных типов элементов управления, которые являются «ожидаемой» функциональностью в мире web2.0, даже для внутренних приложений. См. ScottGu статью для получения дополнительной информации о стоимости последнего пункта.

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

Answer 2

Зависит от пользователя

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

Если пользователь является домашним пользователем ... они, вероятно, не будут заботиться о наличии отладочной информации или нет. При условии, что вы удалите все свои следы:)

Если это бизнес , который ищет скудную машину без раздувания, тогда дайте им урезанную версию.

Зависит от того, где находятся ваши бизнес / коммуникационные цели и ограничения.

Answer 3

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

Кроме того, одно золотое правило, которое я изо всех сил пытался реализовать на своем рабочем месте (и пока еще не достигло полного успеха): никогда НИКОГДА не показывать свой код. Если пользователь разбирается в технологиях, он будет знать, что происходит, и будет плохо о вас думать. Если ваш пользователь не такой, он подумает, что его компьютер одержим дьяволом, и плохо о вас подумает.

Answer 4

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

Но в зависимости от секретных данных заблокируйте отладочную версию.

Answer 5

Кроме уже упомянутых производительности, размера и декомпиляции ...

Безопасность: Информация об отладочных сборках и отладке (например, файлы pdb) содержит много информации об исходном коде, которая не только значительно облегчает декомпиляцию, но также позволяет пользователям знать внутренние детали, такие как имена файлов и сетевые пути. Многие компании могут считать эту информацию очень конфиденциальной.

Answer 6

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

Иногда оптимизатор вызывает ошибки, иногда скрывает их, но, по крайней мере, у вас есть возможность сузить проблему. Для меня это творит чудеса в среде «черного ящика», такой как Raytheon, где получить дамп ядра было невозможно, и трассировка стека пришла по факсу с большим черным маркером по всему этому.

Answer 7

Вы выпускаете программное обеспечение? (Это вопрос «Да», «Нет», «Да, но ...» не считается)

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

Answer 8

Мое дерево решений выглядит так:

Программа написана на Java?

Да - тогда выпуск в режиме отладки в порядке. JIT позаботится об оптимизации

В противном случае - интенсивность работы программы?

Нет - выпуск в режиме отладки в порядке.

Да - тогда компилировать только горячую точку в режиме выпуска.

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

Answer 9

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

Answer 10

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