«Engineering for failure (разработка с учетом возможности отказа)» – это, возможно, плохое выражение, но в действительности это именно то, что требуется для обеспечения надежной и заслуживающей доверия обработки информации.
СБ: Безусловно верно, что при написании кода и разработке систем в голове должна сидеть мысль: «А что здесь может поломаться?». Причин может быть множество, и возможные линии поведения зависят от типа приложения или программного обеспечения. При написании программы типа Microsoft Word они совсем не те, что при разработке кардиомонитора.
БЛ: В случае кардиомонитора вы обязаны поддерживать работу сердца, а в случае Microsoft Word можно всего лишь выдать пользователям «синий» экран, к которому все привыкли.
СБ: Но в случае кардиомонитора вряд ли разумно спрашивать пользователей, хотят ли они поддерживать работу сердца, поскольку ответ очевиден, а в случае Word иногда стоило бы спросить пользователей, как поступать в создавшейся ситуации.
БЛ: Иногда можно спрашивать пользователя, хотя лучше было бы спросить подсистему, что она собирается сделать для самовосстановления, или прекратить ее работу в зависимости от ситуации.
СБ: Вы действительно противопоставляете отказы системы ошибкам пользователей?
БЛ: Я не считаю «отказами» ошибки пользователей, такие как ввод неверных данных. Это нормальное явление. Вряд ли неправильное написание go to вызовет ошибку в работе компилятора. Такие вещи являются ожидаемыми.
СБ: Что же такое, по Вашему мнению, ошибка?
БЛ: Ошибка возникает в каждом случае, когда некоторый используемый компонент не выдает ожидаемого результата, будь то обращение к основной памяти, которое не может быть выполнено из-за проблем с контролем четности, безрезультатный обмен данными с диском или вызов подпрограммы, в которой возникает исключительная ситуация. «Меня попросили выполнить действие X, а я этого не сделал.»
Хороший принцип разработки состоит в следующем: либо делайте то, что вас просят, либо говорите, что вы это делать не будете, и объясняйте причину, но не делайте ничего другого.