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

Я не программист космических челноков, я скромный Flash-разработчик, поэтому я пишу IL только для программных программ с дефектами безопасности виртуальных машин. Хотя статистически, возможно, я лучше программистов космических челноков в программировании, потому что пока мой код имеет 0%-ную смертность.

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

И именно здесь этот поезд неудача — не выход начинает сходить с рельсов (и это ЕСТЬ поезд), потому что оказывается, что неправильное использование вещей — это очень человеческое поведение. Дайте мне систему, и я обещаю вам, что смогу использовать ее неправильно. Напишите систему, и единственная уверенность в том, что кто-то другой будет использовать ее не так, как вы предполагали. И, честно говоря, Вселенная, похоже, тоже так делает, поэтому мы изобрели ECC RAM, чтобы эти чертовы космические лучи не влияли на наши куриные обеды в PUBG. Таким образом, когда мы пишем, нам приходится долго и упорно думать о различных сбоях систем, которые мы пишем, и сбоях систем, которые мы потребляем.

«Базовые системы не могут выйти из строя» — знаете, как ввод-вывод. Основное требование для любого ядра. Очень странно, что S3 реплицирует данные между зонами доступности или что правильное использование любого интерфейса ввода-вывода заключается в том, чтобы просто пытаться писать в него, отлавливая всплывающие ошибки.

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

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

Недавно я поклеил обои в нашей ванной наверху. Дело в том, что листы обоев, вероятно, имеют другую топологию, чем ваша стена. Это, к сожалению, математическая истина изометрии (по крайней мере, для неэластичных обоев). В результате вы получаете морщины здесь и там. Что тогда делать с этими морщинами? Ну, во-первых, вы не игнорируете их. Затем вы группируете их вместе, чтобы получились более крупные морщины, затем перемещаете их в место, где морщины не так важны, например, за туалетным столиком или под выключателем.

Именно так мы должны создавать программные системы.

Вместо того, чтобы искоренять множество мелких отказов, прорезая дыры в наших обоях — попробуйте сориентировать дизайн системы вокруг крупных отказов, которые вытряхивают более мелкие. Затем вместо того, чтобы исправлять их, задокументируйте их. Иногда (не ненавидьте меня) документация ЯВЛЯЕТСЯ исправлением.

Это метод обоев проектирования систем.