Отдельные сборки 'отладки' и 'выпуска'?
Я написал эту небольшую функцию несколько лет назад:
function sqlvprintf($query, $args)
{
global $DB_LINK;
$ctr = 0;
ensureConnection(); // Connect to database if not connected already.
$values = array();
foreach ($args as $value)
{
if (is_string($value))
{
$value = "'" . mysqli_real_escape_string($DB_LINK, $value) . "'";
}
else if (is_null($value))
{
$value = 'NULL';
}
else if (!is_int($value) && !is_float($value))
{
die('Only numeric, string, array and NULL arguments allowed in a query. Argument '.($ctr+1).' is not a basic type, it\'s type is '. gettype($value). '.');
}
$values[] = $value;
$ctr++;
}
$query = preg_replace_callback(
'/{(\\d+)}/',
function($match) use ($values)
{
if (isset($values[$match[1]]))
{
return $values[$match[1]];
}
else
{
return $match[0];
}
},
$query
);
return $query;
}
function runEscapedQuery($preparedQuery /*, ...*/)
{
$params = array_slice(func_get_args(), 1);
$results = runQuery(sqlvprintf($preparedQuery, $params)); // Run query and fetch results.
return $results;
}
Это позволяет запускать операторы в однострочном C # -ish String.Format, например:
runEscapedQuery("INSERT INTO Whatever (id, foo, bar) VALUES ({0}, {1}, {2})", $numericVar, $stringVar1, $stringVar2);
Он избегает использования типа переменной. Если вы попытаетесь параметризовать имена таблиц и столбцов, это будет терпеть неудачу, поскольку она помещает каждую строку в кавычки, которая является недопустимым синтаксисом.
ОБНОВЛЕНИЕ БЕЗОПАСНОСТИ: предыдущая версия str_replace разрешала инъекции, добавляя токены {#} в пользовательские данные. Эта версия preg_replace_callback не вызывает проблем, если замена содержит эти токены.
18 ответов
Это могло бы быть незначительно, но это составляет в целом то, что другие сказали здесь. Одно из преимуществ наличия тестовых сборок конечных версий QA - то, что со временем созданный в отладке и входе поддержки Вашего программного обеспечения будет совершенствоваться из-за потребностей разработчиков, которые должны выяснить, почему вещи идут не так, как надо в QA.
, Чем больше разработчики должен отладить сборки конечных версий, тем лучшие инструменты Вы будете иметь позже, когда клиенты начнут иметь проблемы. Конечно, никакая причина для разработчиков работать над сборками конечных версий как часть цикла разработки.
кроме того, я не знаю компании-разработчика программного обеспечения, которая имеет достаточно долго циклы для предоставления издержек переключающегося QA от отладки до сборок конечных версий на полпути в течение периода тестирования версии. Имея необходимость сделать полный цикл QA - что-то, что слишком часто происходит довольно редко.
Я учился создавать версию выпуска с.PDB файлами давно так, чтобы я мог отладить версию выпуска. То, что много программистов склонно забывать, - то, что при выполнении отладочной версии, со всей выключенной оптимизацией, Вы отлаживаете различную программу в целом. Это может вести себя как сборка конечных версий (по большей части), но это - все еще различная программа, чем сборка конечных версий.
, Кроме того, отлаживая сборку конечных версий не является настолько трудным. И если Вы получаете дамп катастрофического отказа, необходимо быть в состоянии сделать это так или иначе.
Если у Вас есть реальная группа QA, на которую можно рассчитывать, чтобы полностью протестировать вещь, я сказал бы, делают сборки отладки, пока Вы не рядом с выпуском, и затем удостоверяетесь, что полный цикл QA сделан на той же сборке, это идет наружу.
, Хотя по крайней мере в одном случае мы выпустили что-то, что все еще имело некоторый код отладки в нем. Единственное последствие было им, выполнил крошечный бит медленнее, и файлы журнала были довольно чертовски большими.
В моей компании у нас есть и Отладка и Выпуск. - Разработчики используют отладочную версию, чтобы правильно найти и исправить ошибки. - Мы используем TDD и таким образом, у нас есть большой набор тестов, что мы работаем на нашем сервере, который тестирует обе отладочной сборки и конфигурации сборки конечных версий, а также сборки 64/32, которые мы имеем также.
Поэтому при использовании конфигурации "отладки" помогает разработчику найти ошибку быстрее нет никакой причины не использовать ее - когда код входит в сервер (чтобы быть далее протестированным) или рассмотрел, мы используем "Выпуск" один.
Посмотрите этот What' s Ваше самое спорное мнение о программировании?
кавычка:
Мнение: Никогда не имейте различный код между "отладкой" и "выпустите" сборки
, главная причина, являющаяся тем кодом выпуска почти никогда, не тестируется. Лучше для имения того же кода, работающего в тесте, как это находится в дикой природе.
Я думаю, что компромисс прост: да, только со сборкой конечных версий Вы действительно тестируете то, что на самом деле поставляется. С другой стороны, Вы действительно расплачиваетесь в простоте отладки для Ваших разработчиков и/или производительности для пользователя, так Вам решать для проверки обоих случаев.
На большей части носителя - к крупным проектам, простота отладки будет гарантировать лучший продукт для Ваших пользователей в конце.
здесь мы разрабатываем в режиме отладки и делаем все поблочное тестирование в режиме выпуска. мы - небольшой магазин с только некоторыми (под 12) приложение для поддержки в пределах от Классического ASP, ASP.NET, VB.Net и C#. У нас также есть преданный человек для решения всего тестирования, отлаженные проблемы отброшены назад разработчикам.
Это - компромисс. Учитывая, что циклы ЦП являются дешевыми и добирающиеся более дешевый, в то время как человеческие циклы остаются дорогими, это имеет много смысла поддержать только единственную версию большой, сложной программы - отладка (фронтон) версия.
Всегда утверждения использования всегда более безопасная политика, чем никогда использование их. При создании отдельных отладочных версий и версий выпуска, повторно включите любой #define d символы, необходимо гарантировать, что утверждения включены в версии выпуска также.
Я всегда подписывал на "Поставку, что Вы отлаживаете, таким образом, можно отладить то, что Вы поставляете" подход по всем причинам, которые Вы перечисляете в своем вопросе.
Мы всегда создаем обоих, которых даже не рассматривают не выполнением так. Включение параметров отладки увеличивает Ваш размер кода и замедляет производительность, возможно не проблема с Вашим типом программного обеспечения при тестировании, но что, если клиент выполняет код плюс 5 других приложений...
в проблемах с тестированием можно разобраться при помощи автоматизированного тестирования, таким образом, Вы - сборка конечных версий, может быть легко протестирован, когда Вы думаете, что Вы готовы выпустить. Отказ Ваших разработчиков или компании для надлежащего тестирования сборок конечных версий не является отказом в идее сборок выпуска и отладки, но в разработчиках и или компания.
На Вашей последней точке, я никогда не призывался, чтобы отладить сборку конечных версий, только зафиксировать ее...
Я думаю, что это зависит от размера проекта и какая система сборки и тестирование, которое Вы используете.
при наличии автоматизированной системы сборки, и просто выполнить модульные тесты и функциональные испытания на данной сборке, тогда у Вас никогда не должно быть проблем с несколькими типами сборки.
Разработчики работают со сборками отладки, QA, и все остальные используют версию выпуска, которую мы называем "производством". Основное преимущество для этого состоит в том, что в отладочной сборке, мы можем добавить много дополнительного кода и утверждений. Некоторые объекты содержат дополнительные сведения, которые имеют быть бесполезное кроме тех случаев, когда, просматривая код в отладчике. Некоторые объекты проверяют себя периодически, чтобы удостовериться, что вся информация состояния последовательна. Эти вещи делают отладочную версию намного медленнее, но они помогли нам не найти конец ошибок, которые были бы адом для нахождения в производственной сборке.
, Поскольку я сказал, весь наш QA и тестирование производительности использует производственные сборки, и мы действительно иногда сталкиваемся с проблемами, которые обнаруживаются в производстве, но не в отладке. Но они относительно редки, и как разработчик, преимущества отладки, отладочная сборка, а не производство создает, далеко перевешивают ту проблему.
При разработке с Java я ненавижу неотладочные версии. Когда исключение выдается, Вы не получаете информации строки, которая затрудняет или даже невозможный разыскать ошибки. Кроме того, различие во время выполнения между отладкой и неотладкой составляет приблизительно 5% с Java 5 или позже, таким образом, это не действительно без проблем и с сегодняшними жесткими дисками, размер больше не имеет значения.
Зато отладочные версии использования:
- Отслеживания стека содержат всю информацию, в которой Вы нуждаетесь
- , Переменные могут быть исследованы
- , Если у Вас есть проблема в производстве, можно просто присоединить к рабочему процессу, не имея необходимость останавливать сервер сначала для установки отладочной версии.
- Вы не будете пойманы умными ошибками оптимизации
- , сборка более проста (всего один артефакт)
Согласно моему ответу в связанном потоке, мы также используем ту же сборку для отладки и выпуска по очень похожим причинам. 10%-20% увеличения производительности от оптимизатора имеют тенденцию быть очень незначительными когда по сравнению с ручными оптимизациями на уровне алгоритма. Единственная сборка удаляет много потенциальных ошибок. Конкретно;
-
Неинициализированные переменные и маленькое переполнение буфера могут закончиться с совсем другими результатами в отладке и оптимизированных сборках конечных версий.
-
Даже с доступной символьной информацией, отлаживая оптимизированный выпуск может быть трудным, поскольку объект не соответствует источнику, например, переменные, возможно, были оптимизированы, и код, возможно, был перестроен. Таким образом ошибки, сообщенные в протестированных сборках конечных версий, могут быть более трудными, и следовательно трудоемкими, для разыскивания.
сравнивавший неоптимизированные и оптимизированные сборки при автоматизированных регрессионных тестах, увеличение производительности, обеспеченное оптимизацией, не обеспечивает достаточно дополнительного значения для имения двух сборок в моем случае. Это, может стоить отметить, что программное обеспечение, которое я разрабатываю, является очень голодным ЦП (например, создание и управление большими поверхностными моделями).
, таким образом, необходимо создать выпуск, который Вы можете, если необходимая отладка... это может означать включать отладочные символы и отключать некоторую оптимизацию, даже в сборке 'выпуска'.
Ummm..., это кажется на выполнение отладочной сборки мне... право?
часть, где Вы пошли не так, как надо, является этим оператором:
я думаю, что лучше выпустить версию программного обеспечения, которое Ваши разработчики на самом деле протестировали
, Разработчики не делают тестового кода. Тестовый тестовый код.
Ваши модульные тесты должны протестировать ВЕСЬ конфигурации сборки. Не заставляйте своих разработчиков работать с одной рукой, связанной за их спиной - позволяют им использовать все средства отладки, которые они имеют в там распоряжении. Отладочная сборка один из них.
Относительно утверждает: использование утверждений значительно зависит от того, программируете ли Вы согласно контракту. Если Вы делаете, то утверждения просто проверяют контракт в отладочная сборка.
Наша политика состоит в том, чтобы сделать, чтобы разработчики работали над сборками Отладки, но ВСЕ ОСТАЛЬНЫЕ (QA, BAS, продажи и т.д.) выполняют версию выпуска. Вчера я должен был исправить ошибку, которая только разоблачила в сборке конечных версий его, было очевидно, что происходило просто, ПОСКОЛЬКУ это только обнаружилось в выпуске
, Это - первое здесь в этом магазине, и я был здесь 18 месяцами или около этого.
то, Где вещи становятся волосатыми, - когда Сборка конечных версий делает разные вещи для отладочной сборки - Да, я был к черту и видел это в некотором очень старом, очень тягучем производственном коде.
я не вижу оснований, почему не иметь и если единственной разницей между конфигурациями являются отладочные символы и оптимизации.
Наличие отдельной отладки и сборок конечных версий является хорошей идеей, потому что это действительно делает разработку легче.
, Но сборки отладки должен быть для разработки только, не для тестирования. Вы тестируете сборки конечных версий только. И Вы не используете разработчиков для тестирования тех сборок, Вы используете тестеры.
Это - простая политика, которая дает лучший из обоих миров, IMO.
Редактирование: В ответ на комментарий, я думаю, что очевидно, что отладка и сборки конечных версий (могут) генерировать различный код. Думайте, что "-DDEBUG" по сравнению с "-DNDEBUG", и "#if определенный (ОТЛАЖИВАЮТ)", и т.д.
, Таким образом, жизненно важно, чтобы Вы протестировали код, который Вы заканчиваете тем, что поставили. Если Вы делаете , генерируют различный код в отладке и сборках конечных версий, который означает тестировать дважды - независимо от того, тестируется ли это тем же человеком.
Отладочные символы не то, что большие проблема, как бы то ни было. Всегда создавайте с отладочной информацией, сохраняйте копию неразделенного двоичного файла, но выпускайте разделенный двоичный файл. Пока Вы отмечаете каждый двоичный файл с номером сборки так или иначе, необходимо всегда быть в состоянии определить, какой неразделенный двоичный файл соответствует разделенному двоичному файлу, который необходимо отладить...
то, Как разделить двоичные файлы и символы загрузки в Вашем отладчике из внешнего источника, зависимо от платформы.
По-моему, это обсуждение, упускающее очень важную суть:
Это действительно зависит от того, какой проект это!
при создании собственного компонента (C/C++) проект, Вы будете в действительности вынуждены создать сборки отладки, просто потому что оптимизация компилятора может сделать отладку почти невозможного в некоторых случаях.
при создании веб-приложений, Вы могли бы скорее хотеть просто иметь одну сборку (хотя "сборка" скорее вводит в заблуждение для некоторых веб-приложений), который может активировать регистрирующиеся опции во время времени выполнения.
, Хотя собственный проект C++ и веб-приложение PHP являются, очевидно, не всеми видами проекта, которые существуют, я надеюсь что моя объясненная точка.
P.S.: При разработке для C# Вы сталкиваетесь со случаем границы с тех пор, хотя использование отладочная сборка отключает оптимизацию компилятора, по моему опыту, Вы не столкнетесь почти со столько же различия сколько с C++