Эндрю Хант - Программист-прагматик. Путь от подмастерья к мастеру

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

Каждый знает, что лично он – лучший водитель на планете Земля. Остальному человечеству далеко до него, проезжающего под запрещающие знаки, мотающегося из ряда в ряд, не подающего сигналы поворота, разговаривающего по телефону, читающего за рулем газету и просто не живущего по общепринятым нормам. Так что мы ездим осторожно. Мы обнаруживаем неприятность до того, как она происходит, ожидаем непредвиденное и никогда не оказываемся в положении, из которого не сможем выпутаться сами.

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

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

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

В разделе «Программирование с применением утверждений» описан простой метод проверки «на ходу» – программа, которая активно проверяет ваши предположения.

Исключения, как и любая другая методика, может причинить больше вреда, чем пользы, если ее применять неправильно. Мы обсудим эти аспекты в разделе «Случаи, когда необходимо использовать исключения».

По мере того как ваши программы приобретают большую динамику, вы начинаете жонглировать системными ресурсами – памятью, файлами, устройствами и т. п. В разделе «Балансировка ресурсов» предлагаются способы того, как не ронять те предметы, которыми вы жонглируете.

Поэтому будем осторожными в этом мире несовершенных систем, устаревших временных масштабов, смешных инструментальных средств и невыполнимых требований.

Если все общество отклоняется от нормы, чтобы понять вас, скорее всего это паранойя.

Работать с компьютерными системами всегда непросто. Работать с людьми еще сложнее. И поскольку мы (как биологический вид) развиваемся достаточно долго, то у нас явно было больше времени на выяснение природы человеческих взаимоотношений. Некоторые из тех решений, к которым мы пришли в течение нескольких последних тысячелетий, могут быть применены и к созданию программного обеспечения. Одним из лучших способов, с помощью которого можно удостовериться в честности заключаемой сделки, является контракт.

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

Допустим, у вас есть контракт на работу, где определены количество отрабатываемых часов и правила поведения, которым вы обязаны следовать. В ответ фирма платит вам заработную плату и предоставляет другие льготы. Каждая из сторон выполняет свои обязательства, а в результате выигрывают все.

Эта идея используется во всем мире – и формальным, и неформальным образом – для того, чтобы помочь людям во взаимодействии. Можем ли мы применить этот же принцип, чтобы способствовать взаимодействию программных модулей? Ответ на этот вопрос положительный.

Бертран Мейер [Меу97b] разработал концепцию проектирования по контракту для языка Eiffel [25] Концепция частично основана на ранней работе Дейкстры, Флойда, Хоара, Вирта и др. Более подробная информация о самом языке Eiffel содержится в сети Интернет, см. [URL 10] и [URL 11]. . Это простая, но мощная методика, сосредоточенная на документировании (и согласовании) прав и обязанностей программных модулей в целях обеспечения корректности программы. Так что же означает «корректная программа»? Это та программа, которая делает не более и не менее того, на что она претендует. Документирование и подтверждение указанных претензий лежит в основе принципа проектирования по контракту (в дальнейшем, для краткости, будем называть его ППК).