WikiDer > Наступательное программирование - Википедия

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

Эта статья является сирота, как никакие другие статьи ссылка на это. Пожалуйста ввести ссылки на эту страницу из Статьи по Теме; попробуйте Инструмент поиска ссылок для предложений. (Сентябрь 2016)

Наступательное программирование это имя, используемое для отделения защитное программирование который явно отклоняется от принципов защиты при работе с ошибками, возникшими в результате программные ошибки. Хотя это название является реакцией на крайние интерпретации защитного программирования, между ними нет принципиального конфликта. Напротив, оскорбительное программирование добавляет явный приоритет не терпеть ошибки в неправильных местах: точка, в которой он отходит от крайних интерпретаций защитного программирования, состоит в том, что он предпочитает наличие ошибок в рамках линии защиты программы, чтобы они были явно очевидными, а не гипотетическим преимуществам безопасности их терпимости.^[1][2] Это предпочтение также оправдывает использование утверждения.

Отличительные ошибки

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

Контрастные примеры:

Стратегии обнаружения ошибок

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

Стратегии:

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

Смотрите также

• Быстро

Рекомендации