Просмотр кода страницы Словарик философствующего информатика

У вас нет прав на выполнение действия «редактирование этой страницы» по следующей причине:

Ваш IP-адрес находится в диапазоне, который был заблокирован на всех вики-сайтах Фонда Викимедиа.

Блокировка наложена участником ‪EPIC‬ . В качестве причины указана Open proxy/Webhost: See the help page if you are affected .

Начало блокировки: 08:48, 2 июля 2024
Конец блокировки: 08:48, 2 июля 2025

Ваш текущий IP-адрес: 206.189.44.186 . The blocked range is 206.189.32.0/20.

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

Для обсуждения блокировки, пожалуйста, оставьте запрос на Meta-Wiki. You could also send an email to the stewards VRT queue at stewards@wikimedia.org including all above details.

Вы можете просмотреть и скопировать исходный код этой страницы.

=== Надёжность ===

Безусловно, программные средства (далее, тут и ранее — ПС) должны работать правильно и надёжно.
Но оба упомянутых термина допускают большую свободу интерпретации.
Например:

'''Работать правильно''' — это
* так, как представляет себе это заказчик;
* так, как понял и сформулировал менеджер проекта;
* так, как записал в тех. задании постановщик задания;
* так, как понял это задание программист;
* так, как решил сделать программист, который (иногда заслуженно) считает себя умнее постановщика задания, менеджера и, тем более, заказчика.
Ясно, что данные пункты могут отличаться, а полученное в результате ПС может отличаться от всех этих пунктов. Это отдельная тема, и мы не будем её здесь развивать. Предположим, что понятие правильности удивительным образом вполне чётко, полно и непротиворечиво описано в некоторой спецификации логики работы ПС.

Под надёжностью ПС можно понимать правильность работы для '''всех''' входных данных.
Для большинства сложных систем такая ''абсолютная надёжность'' — очень серьезное требование. Часто оно просто недостижимо. Какой бы полной не была спецификация логики работы ПС, она просто не может
включить (описать), каким должно быть поведение ПС в экстремальных условиях.

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

Понятие ''надёжность'' более адекватно (прагматично) отражает то, что в реальности можно требовать
от ПС:

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

В экстремальных ситуациях словосочетание «правильность работы» имеет смысл заменить на
«логичность поведения ПС». Даже в экстремальных ситуациях ПС должно делать
попытки «выжить» и обеспечить сохранность данных, а также
предоставить возможность восстановления работоспособности после «перезагрузки».

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

[[#Самодокументированность (code self-documentation)|Самодокументированность]] и
[[#Cамопроверяемость (code self-verification)|самопроверяемость]] являются важными
общепринятыми методологиями достижения надёжности кода. Они позволяют без тестирования
продукта, малыми усилиями, обеспечить недопущение и устранение большого числа ошибок.

Кроме того, надёжность ПС гарантируется с помощью массового
и многопланового [[#Тестирование|тестирования]] ПС.

Также существуют специализированные инструменты,
осуществляющие анализ кода и проверяющие выполнение необходимых условий.
Эти условия указываются непосредственно в коде, и непосредственно
связаны с требованиями, предъявляемыми к ПС в спецификации логики работы.
Например, это могут быть post- и prerequisites conditions —
условие, которым должны удовлетворять данные в момент вызова некоторой функции,
и в момент завершения выполнения функции.
Задача ''доказательства правильности работы программ'' довольно сложна,
но уже есть прецеденты создания программ, для которых с использованием специальным программ
доказано, что они ''всегда'' работают правильно.

Выделенное слово «всегда» и есть такое слово, степень приближения к которому
измеряется надёжностью.

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

Часто излишнее стремление к надёжности приводит к слишком жесткой архитектуре и
слишком медленному коду. Например, в коде в самых различных
местах можно вставлять кусочки, проверяющие корректность данных и состояний устройств,
с которыми будет связано следующее действие.
Здесь, как и везде в информационных технологиях, важно чувствовать баланс
и не доводить стремление к надёжности до паранойи.
Важно распределить задачу достижения надёжности по различным этапам разработки ПС,
на каждом этапе делать то, что может быть сделано на этом этапе меньшими усилиями, чем на других.
Шаги, предпринимаемые для достижения надёжности, не должны сильно усложнять разработку.
<!--

=== Самодокументированность (code self-documentation) ===

=== Cамопроверяемость (code self-verification) ===

=== Экстремальное программирование ===
-->

Возврат к странице Словарик философствующего информатика.

Источник — https://ru.wikibooks.org/wiki/Словарик_философствующего_информатика