Что-то не так с выпуском программного обеспечения в режиме отладки?
Мы все знаем, что "Режим отладки" должен использоваться для разработки, потому что компилятор производит больше отладочной информации, а "Режим выпуска" должен использоваться для производственных выпусков, потому что компилятор производит оптимизированный код.
Однако, скажем, если вы создаете программное обеспечение, которое используется только внутри организации, и производительность кода не является большой проблемой, потому что программное обеспечение должно выполнять много операций ввода-вывода файлов и запросов к базе данных. В этом сценарии у меня будет большой соблазн просто выпустить программное обеспечение в "режиме отладки", потому что эта дополнительная информация об отладке немного облегчает будущее обслуживание.
Есть ли еще веская причина для выпуска программного обеспечения в режиме выпуска в этом случае?
20 ответов
Две проблемы, о которых я могу думать:
Отладочные сборки часто добавляют отступы в буферы. Вот почему иногда вы получаете программы, которые, кажется, работают в режиме отладки, но аварийно завершают работу при выпуске. Похоже, это рабочее слово, поскольку переполнение буфера - это просто случайность, ожидающая своего появления.
Странные вещи случаются в отладочных сборках. Однажды я работал над долго работающим приложением, которое зависало каждые двадцать дней или около того. Оказывается, во время выполнения C счетчик (используемый для помощи в отладке) увеличивался при каждом выполнении malloc / free. Если счетчик переполнен - kaboom! Только по этой причине я бы никому не рекомендовал развертывать отладочные двоичные файлы - вы просто никогда не знаете, какие сюрпризы могут ожидать вашего клиента.
Возможные причины:
- Отладка обычно не компилируется для производительности
- Размер отладочного приложения (обычно) намного больше, чем у компиляции релиза.
- Если кто-то попытается перепроектировать ваше приложение (по какой-либо причине), тогда это станет намного проще.
ОБНОВЛЕНИЕ: 4. Как указывалось, производительность компоновщика, но я бы подумал, будет далеко внизу списка:p Сколько раз вы выпускаете продукт по сравнению с отладочными компиляциями?
Если вы готовы отказаться от вышесказанного, то нет никаких реальных причин, почему бы и нет.
Тот факт, что вы спрашиваете, говорит о том, что вы можете воспользоваться преимуществом режима отладки. Если эти преимущества перевешивают вашу моральную вину, тогда я говорю: продолжайте и сделайте это. Эти преимущества, вероятно, носят механический и информационный характер и имеют отношение к вашей работе, хотя отсутствие чувства вины на самом деле не помогает вам создавать лучшее программное обеспечение. Это может помочь вам лучше спать, но кого это волнует?
Я предполагаю, что существует намного больше установленного отладочного кода, чем мы (разработчики) готовы признать.
Лично я знаю много производственных систем, которые развертываются на клиентах с кодом, скомпилированным в режиме отладки.
У меня нет никаких личных возражений против внутренней доставки сборки Debug, при условии, что она работает (некоторые версии Debug не будут работать на машинах не-dev без установки соответствующих библиотек отладки... столкнулся с этим, когда я программировал C++/ Код МФЦ).
Несколько более сложный подход заключается в использовании сервера символов, который автоматически обновляется с помощью символов в процессе сборки.
Если вы отлаживали проблему с компьютера клиента, укажите облегченный отладчик на свой сервер символов (убедитесь, что версии совпадают), а затем начните отладку.
Используйте режим выпуска, но скомпилируйте с включенной отладочной информацией и разверните файлы pdb с исполняемыми файлами. Вы можете отлаживать исполняемые файлы так же, как и отладочные - разницы нет, вам просто нужно сгенерировать файлы pdb при сборке.
Выпуск и запуск отладочной сборки может быть опасным, поскольку она скрывает ошибки в вашем коде, которые будут появляться только в режиме выпуска.
У меня есть смутное воспоминание о том, что если вы возьмете двоичные файлы, скомпилированные в Debug, на компьютер, на котором не установлены библиотеки среды выполнения Debug C (что обычно означает, что у него нет IDE, поэтому большинство пользователей попадают в эту категорию), он будет Барф с сообщением об ошибке. Я не знаю, относится ли это к Windows и / или C++. Возможно, я также запоминаю... но вам непременно следует проверить, произойдет ли это, потому что, если я прав, это будет основной причиной для компиляции в режиме релиза.
дополнительная информация об отладке облегчает дальнейшее обслуживание.
Это зависит от того, что вы подразумеваете под "дополнительной информацией отладки".
Если вы имеете в виду отладочные сообщения, вы, вероятно, должны использовать Traceне Debugи использовать переключатели трассировки и прослушиватели трассировки, определенные в файле конфигурации, для управления поведением журналирования во время выполнения.
Если вы имеете в виду знание имени члена и номера строки в случае исключения, вам не нужно распространять отладочные сборки для получения этой информации; просто распространять .pdb файлы с вашим исполняемым файлом. Exception класс использует информацию из .pdb файл независимо от того, установили ли вы какие-либо константы компиляции.
Компиляция любого приложения в режиме отладки добавляет к приложению код, который используется (почти) исключительно компилятором или IDE для отладки, пошагового выполнения кода и т. Д. Эти функции отладки практически не используются в реальной жизни. Если вы хотите опубликовать приложение для общественности, лучше всего скомпилировать его в режиме выпуска. Кроме того, релиз-приложения...
- Гораздо быстрее и стабильнее
- Оптимизирован для машины
- Меньше по размеру
- Более безопасный (сложнее декомпилировать / взломать)
- Более эффективный и простой на оборудовании
Если у вас есть опция режима выпуска, почему бы не использовать ее? У вас всегда будет отладочная версия для разработки, или, если что-то пойдет не так, и вы всегда можете упаковать приложение, созданное в Debug, и / или исходный код в версию, собранную в Release.
Кроме того, у вас также может быть возможность создания приложения для определенных платформ. Компиляция с использованием режима Release упростит приложение для указанной платформы, сделав его гораздо более стабильным.
Даже если скорость не является проблемой, нет причин не использовать режим Release при компиляции.
Зависит от пользователя
Если пользователь технический, предоставление дополнительного пакета отладки для символов может помочь им отладить от вашего имени или представить дополнительную техническую информацию об ошибке... экономя ваши деньги / время.
Если пользователь является домашним пользователем... им, вероятно, будет все равно, есть ли отладочная информация или нет. При условии, что вы удалите все ваши следы-отстой:)
Если это бизнес, который ищет скудный, не раздувающий машину, то предоставьте им урезанную версию.
Зависит от того, где находятся ваши бизнес / коммуникационные цели и ограничения.
У меня в основном две проблемы с релизом отладки:
- Отладочная информация может быть большой и ненужной страховой проверкой для будущего обслуживания, которую можно избежать другими способами.
- Диагностика - это аспект вашего приложения, который не должен иметь отношения к вашей сборочной конфигурации или зависимости от нее.
Я думаю, что важно разработать и сохранить логику приборов и диагностики в вашем приложении как аспект или сквозную проблему. Если вы слишком полагаетесь на информацию, предоставленную отладочной версией вашего кода:
- Можете ли вы гарантировать, что это будет отладочная версия, которая будет выпускаться каждый раз при выпуске новой версии вашего приложения? плохая документация, кто-то другой делает это и т.д.
- Приложения имеют тенденцию к росту функциональности и сложности. В то время как производительность и размер вашего приложения из-за отладочной версии не могут быть проблемой в данный момент. Все может сложиться и привести к потенциальным проблемам. В случае проблем с производительностью вы можете даже не приписывать их отладочной версии.
Вы все еще можете собирать ценную информацию в версии выпуска. Трассировка стека все еще должна быть доступна в случае исключений. Вы можете не видеть исходный файл и номера строк, но вы все равно можете видеть, какие методы вызываются. Однако вы все равно должны создавать и хранить символы отладки для вашей сборки выпуска. Эти символы позволят вам отладить вашу версию релиза (вы даже можете настроить сервер символов). Из-за оптимизации кода отладочная информация, скорее всего, не будет соответствовать 100% кода, например, отладочная информация, относящаяся к оптимизированному оператору и т. Д., Но вы все равно должны иметь возможность отладить большую часть его в порядке. Другая информация, такая как вводимые пользователем данные, промежуточные данные, выполненный код базы данных и т. Д. Отладочный выпуск не поможет вам в любом случае, поскольку он не собирает эту информацию. Вы должны следить за ними самостоятельно.
Если вы используете.NET, вы можете взглянуть на Tracing and Instrumentation. Вы также можете рассмотреть возможность использования существующей платформы, такой как Microsoft Enterprise Library или log4net. Если это приложение.NET, вы также можете запросить JIT-компилятор для создания информации отслеживания для версии выпуска вашего приложения в качестве опции. Проверьте эту статью MSDN.
Вы были независимы от платформы в этом вопросе, но этот совет о том, почему не включать режим отладки в производство на ASP.Net, демонстрирует некоторые (по общему признанию, связанные с производительностью) причины не делать этого.
1) Компиляция страниц ASP.NET занимает больше времени (так как некоторые пакетные оптимизации отключены)
2) Код может выполняться медленнее (поскольку некоторые дополнительные пути отладки включены)
3) Гораздо больше памяти используется внутри приложения во время выполнения
4) Скрипты и изображения, загруженные из обработчика WebResources.axd, не кэшируются
Последний пункт - своего рода убийца производительности для определенных типов элементов управления, которые являются "ожидаемой" функциональностью в мире web2.0, даже для внутренних приложений. См. Статью ScottGu для получения дополнительной информации о стоимости последнего пункта.
Возможно, лучший способ подвести итог контраргументу - "это зависит от того, как вы определяете производительность кода".
Помимо уже упомянутой производительности, размера и декомпиляции...
Безопасность: информация об отладочных сборках и отладке (например, файлы pdb) содержит много информации об исходном коде, что не только значительно упрощает декомпиляцию, но и позволяет пользователям знать внутренние детали, такие как имена файлов и пути к сети. Многие компании могут считать эту информацию очень конфиденциальной.
Я думаю, что важно следовать хорошим стандартам, практикам и процедурам. Просто потому, что приложение используется только для внутренних целей, не является хорошей причиной, чтобы позволить себе быть ленивым. Хотя я испытываю сильные чувства по поводу "правильного" способа ведения дел, я считаю, что привычки писать хорошее программное обеспечение перевешивают преимущества, в конечном счете, обмана с использованием отладочной версии. Добавьте некоторую обработку исключений, изучите подводные камни систем, против которых вы кодируете - это сделает весь код, который вы пишете, лучше.
Выпустить две версии, одну с надписью, если появляются ошибки, используйте эту..
Но в зависимости от конфиденциальных данных заблокируйте отладочную версию.
Если это веб-сайт или служба, и производительность не является проблемой, то обязательно отключите ее в режиме отладки. Если это настольное приложение, подумайте, удобна ли версия режима отладки в том, как она обрабатывает ошибки. Если это так, то я бы выпустил и отладочную версию.
Я лично верю в среднее решение между отладкой и выпуском, то есть вы регистрируете достаточно, чтобы вы могли воспроизвести ошибку, если она произойдет. Когда ваше приложение станет достаточно стабильным, отключите дополнительное ведение журнала с помощью параметра в файле конфигурации. Я понимаю, что это не может быть сделано все время, хотя. Чаще всего, когда ваше приложение работает только в одном месте.
Кроме того, одно золотое правило, которое я изо всех сил старался реализовать на своем рабочем месте (и которое пока не достигло полного успеха): никогда НИКОГДА не показывать свой код. Если пользователь разбирается в технологиях, он будет знать, что происходит, и будет плохо о вас думать. Если вашего пользователя нет, он будет думать, что его компьютер одержим дьяволом, и будет плохо о вас думать.
Мое дерево решений выглядит так:
Программа написана на Java?
Да - тогда выпуск в режиме отладки в порядке. JIT позаботится об оптимизации
В противном случае - Является ли программа CPU Intensive?
Нет - выпуск в режиме отладки в порядке.
Да - тогда скомпилируйте только горячую точку в режиме релиза.
Основное обоснование: гораздо проще поддерживать код, когда отчеты об ошибках генерируются именно из той программы, которая запущена в вашей среде IDE. В IDE вы используете отладочную версию, поэтому вы должны стремиться к выпуску в режиме отладки.
Вот что я обычно делаю с программным обеспечением, которое должно иметь отладочную информацию (обычно это инструменты типа разработки) - я компилирую свой код оптимизированным, но с символьной информацией и связываю таким образом, чтобы я сохранял символьную информацию. Таким образом, когда происходит сбой программного обеспечения, я могу, по крайней мере, получить приличную половину трассировки стека и идею о том, с чего начать размещать дополнительную информацию для регистрации, когда я отправляю клиенту полную отладочную сборку.
Иногда оптимизатор вызывает ошибки, иногда скрывает их, но, по крайней мере, у вас есть возможность сузить проблему. Это творило чудеса для меня в среде "черного ящика", такой как Raytheon, где получить дамп ядра было невозможно, и трассировка стека пришла по факсу с большим черным маркером на всем протяжении.
Вы выпускаете программное обеспечение? (Это вопрос "Да", "Нет", "Да, но..." не считается)
Если так, то почему бы не сделать это должным образом и сделать его настоящим выпуском, чтобы вам не пришлось полагаться на символы отладки, доступные вашим пользователям....