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

Может быть сделано с использованием array_walk (array_walk_recursive, если необходимо)

$ arr - массив, который вы хотите найти в

$largestElement = null;

array_walk($arr, function(&$item, $key) use (&$largestElement) {
    if (!is_array($largestElement) || $largestElement["Total"] < $item["Total"]) {
        $largestElement = $item;
    }
});
35
задан oscarkuo 3 June 2009 в 21:37
поделиться

20 ответов

Я могу вспомнить две проблемы:

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

  2. Странные вещи происходят в отладочных сборках. Однажды я работал над долго работающим приложением, которое вылетало каждые двадцать дней или около того. Оказывается, во время выполнения C счетчик (используемый для облегчения отладки) увеличивался каждый раз, когда выполнялась malloc / free. Если счетчик переполнился - бах! Только по этой причине я бы никогда никому не рекомендовал развертывать двоичные файлы отладки - вы просто никогда не знаете, какие сюрпризы могут ждать вашего клиента.

29
ответ дан 27 November 2019 в 06:51
поделиться

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

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

0
ответ дан 27 November 2019 в 06:51
поделиться

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

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

0
ответ дан 27 November 2019 в 06:51
поделиться

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

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

0
ответ дан 27 November 2019 в 06:51
поделиться

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

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

0
ответ дан 27 November 2019 в 06:51
поделиться

Мое дерево решений выглядит следующим образом:

Написана ли программа на Java?

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

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

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

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

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

0
ответ дан 27 November 2019 в 06:51
поделиться

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

0
ответ дан 27 November 2019 в 06:51
поделиться

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

0
ответ дан 27 November 2019 в 06:51
поделиться

У меня в основном две проблемы с отладочной версией:

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

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

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

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

Если вы используете .NET, вы можете взглянуть на Tracing and Instrumentation . Вы также можете рассмотреть возможность использования существующей инфраструктуры, такой как Microsoft Enterprise Library или log4net. Если это приложение .NET, вы также можете запросить JIT-компилятор для создания информации отслеживания для версии выпуска вашего приложения в качестве опции. Прочтите эту статью MSDN .

t помочь вам в любом случае, поскольку он не фиксирует эту информацию. Вам нужно отслеживать их самостоятельно.

Если вы используете .NET, вы можете взглянуть на Tracing and Instrumentation . Вы также можете рассмотреть возможность использования существующей инфраструктуры, такой как Microsoft Enterprise Library или log4net. Если это приложение .NET, вы также можете запросить JIT-компилятор для создания информации отслеживания для версии выпуска вашего приложения в качестве опции. Прочтите эту статью MSDN .

t помочь вам в любом случае, поскольку он не фиксирует эту информацию. Вам нужно отслеживать их самостоятельно.

Если вы используете .NET, вы можете взглянуть на Tracing and Instrumentation . Вы также можете рассмотреть возможность использования существующей инфраструктуры, такой как Microsoft Enterprise Library или log4net. Если это приложение .NET, вы также можете запросить JIT-компилятор для создания информации отслеживания для версии выпуска вашего приложения в качестве опции. Прочтите эту статью MSDN .

вы также можете запросить JIT-компилятор для генерации информации отслеживания для версии выпуска вашего приложения в качестве опции. Прочтите эту статью MSDN .

вы также можете запросить JIT-компилятор для генерации информации отслеживания для версии выпуска вашего приложения в качестве опции. Прочтите эту статью MSDN .

1
ответ дан 27 November 2019 в 06:51
поделиться

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

  • Намного быстрее и стабильнее
  • Оптимизированы для машины
  • Меньше по размеру
  • Более безопасны (труднее декомпилировать / взломать)
  • Более эффективны и проще аппаратное обеспечение

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

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

Даже если скорость не является проблемой, нет причин не использовать режим Release при компиляции.

1
ответ дан 27 November 2019 в 06:51
поделиться

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

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

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

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

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

1
ответ дан 27 November 2019 в 06:51
поделиться

У меня смутное воспоминание, что если вы возьмете двоичные файлы, скомпилированные в режиме отладки, на компьютер, на котором не установлены библиотеки времени выполнения отладки C (что обычно означает, что у него нет IDE, поэтому большинство пользователей попадают в эту категорию), появится сообщение об ошибке. Я не знаю, относится ли это к Windows и / или C ++. Я тоже могу неправильно вспомнить ... но вы обязательно должны проверить, происходит ли это, как если бы я прав, это было бы основной причиной для компиляции в режиме выпуска.

3
ответ дан 27 November 2019 в 06:51
поделиться

дополнительная отладочная информация немного упрощает дальнейшее обслуживание

Это зависит от того, что вы подразумеваете под «дополнительной отладочной информацией».

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

Если вы имеете в виду знание имени участника и номера строки при возникновении исключения, вам не нужно распространять отладочные сборки для получения этой информации; просто распространите файлы .pdb вместе со своим исполняемым файлом. Класс Exception использует информацию из файла .pdb независимо от того, установлены ли какие-либо константы компиляции.

2
ответ дан 27 November 2019 в 06:51
поделиться

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

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

4
ответ дан 27 November 2019 в 06:51
поделиться

У меня нет никаких личных возражений против отправки сборки отладки внутри компании, при условии, что она работает (некоторые версии отладки не будут работать на машинах, не являющихся разработчиками, без установки соответствующих библиотек отладки ... столкнулся с этим, когда программировал код C ++ / MFC).

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

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

5
ответ дан 27 November 2019 в 06:51
поделиться

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

Лично я знаю множество производственных систем, которые развертываются для клиентов с код, скомпилированный в режиме отладки.

5
ответ дан 27 November 2019 в 06:51
поделиться

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

10
ответ дан 27 November 2019 в 06:51
поделиться

Возможные причины:

  1. Отладка обычно не компилируется для повышения производительности
  2. Размер отладочного приложения (обычно) намного больше, чем при компиляции релиза.
  3. Если кто-то пытается реконструировать ваш приложение (по какой-либо причине), тогда это станет намного проще.

ОБНОВЛЕНИЕ: 4. Как уже указывалось, производительность компоновщика, но я бы подумал, будет ниже по списку: p Сколько раз вы выпускаете продукт по сравнению с отладочными компиляциями?

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

15
ответ дан 27 November 2019 в 06:51
поделиться

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

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

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

3) В рамках приложение во время выполнения

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

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

1
ответ дан 27 November 2019 в 06:51
поделиться

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

Кроме того, одно золотое правило, которое я старался использовать на своем рабочем месте (и еще не полностью удалось сделать): Никогда никогда не позволяйте вашим кодам. Если пользователь Tech Savvy, он узнает, что происходит и плохо думать о тебе. Если ваш пользователь нет, он подумает, что его компьютер обладает дьяволом, и плохо думать о тебе.

0
ответ дан 27 November 2019 в 06:51
поделиться
Другие вопросы по тегам:

Похожие вопросы: