Читаем The Programmers` Stone (Программистский камень) полностью

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

Коммуникационные уровни часто обязаны использовать таймауты, поскольку когда приходит время их работы, единственный способ обнаружить, что удаленное устройство готово к взаимодействию -- послать ему сообщение и дождаться, посылает ли оно ответ. Как долго нужно ждать? "Проблема Византийских полководцев" (`Byzantine Generals' Problem') это иллюстрирует. Поэтому в большинстве современных систем есть таймауты на уровне коммуникации, но нет никакого оправдания использовать их повсюду, и там, где они должны использоваться, они должны быть сокрыты внутри инкапсулирующего объекта, который для целей отладки может быть заменен на детерминированный генератор событий (например, нажатие клавиши).

Проектируй для тестирования

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

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

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

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

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