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

Иногда вы берете старый код и делаете в нем очень важное исправление за пять минут до отправки готового продукта. Времени остается только на то, чтобы бегло взглянуть на структуру кода и прикинуть, как он будет работать. Полный критический разбор проводить некогда, и вам остается только надеяться, что код действительно делает то, что следует, пока не представится возможность проверить это на практике.

• Предположения служат причиной появления кода с ошибками. Очень легко предположить следующее:
• Функцию никогда не станут вызывать таким способом. Ей всегда будут передаваться только допустимые параметры.
• Этот фрагмент кода всегда будет работать, он никогда не сгенерирует ошибку.

Никто не станет пытаться обратиться к этой переменной, если я напишу в документации, что она предназначена только для внутреннего употребления.

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

Опыт показывает, что уверенным можно быть только в одном: в один прекрасный день ваш код по каким-то причинам даст сбой. Кто-то обязательно сделает глупость. Закон Мерфи гласит: «Если какая-нибудь неприятность может произойти, она обязательно случится». Прислушайтесь к автору – он говорит о том, что познал на собственном опыте*.

*Эдвард Мерфи, служивший инженером в ВВС США, сформулировал свой знаменитый закон, когда обнаружил, что некий техник регулярно подключает целый ряд устройств наизнанку. Неправильное подключение было возможно из-за симметричности разъемов. Чтобы избежать этого, пришлось изменить их конструкцию.

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

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

Не делайте никаких допущений. Не зафиксированные формально допущения часто служат причиной отказов, особенно с ростом объема кода.

Учтите еще неприятные обстоятельства, которые нельзя предвидеть ни вам, ни вашим пользователям: недостаток памяти на диске, отказ сети или сбой компьютера. Всегда могут случиться неприятности. И помните, что ошибку совершает не программа – она всегда лишь выполняет то, что вы от нее потребовали. Аварии в системе возникают из-за ошибок в алгоритмах или клиентском коде.

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

Гудлиф Питер, "Ремесло программиста. Практика написания хорошего кода".