94
группы. Как давно понял Иверсон,
2
в систематическом языке высокого уровня
группировка уже проведена, и каждый прямоугольник содержит оператор (рис.
15.2). Поэтому сами прямоугольники являются утомительным и отнимающим место
упражнением в черчении и вполне могут быть удалены. Тогда остаются только
стрелки. Стрелки, связывающие один оператор с другим, расположенным в
следующей строке, излишни, и их можно удалить. Тогда остаются только GO TO, и
если придерживаться хорошей практики программирования и использовать блочные
структуры для минимизации числа GO TO, таких стрелок окажется немного, но они
очень способствуют пониманию. Вполне можно нарисовать их на листинге и вовсе
избавиться от блок-схемы.
В действительности о блок-схемах больше говорят, чем пользуются ими. Я никогда
не видел опытного программиста, который в повседневной деятельности рисовал бы
подробные блок-схемы, прежде чем начать писать программу. Там, где блок-схемы
требуются правилами организации, они почти всегда создаются задним числом.
Многие гордятся использованием специальных программ для генерации этого
«незаменимого инструмента разработки» на основе уже законченной программы.
Думаю, что этот всеобщий опыт не является постыдным и предосудительным отходом
от хорошей практики программирования, признаваться в котором можно лишь с
нервным смешком. Напротив, это результат здравого рассуждения, дающий нам урок
относительно полезности блок-схем.
Апостол Петр сказал о новообращенных язычниках и законе Моисея: «Что же вы
[желаете] возложить на выи учеников иго, которого не могли понести ни отцы наши,
ни мы?» (Деяния апостолов 15:10). То же сказал бы я о программистах-новичках и
устаревшей практике блок-схем.
Самодокументирующиеся программы
Один из основных принципов обработки данных учит, что безрассудно стараться
поддерживать синхронность независимых файлов. Значительно лучше собрать их в
один файл, в котором каждая запись содержит все данные их обоих файлов,
относящиеся к данному ключу.
Тем не менее наша практика документирования программ противоречит собственным
теориям. Обычно мы пытаемся поддерживать программу в виде, пригодном для
ввода в машину, а независимый комплект документации, состоящей из текста и
блок-схем, — в виде, пригодном для чтения человеком.
Результаты этого подтверждают мысль о неразумности поддержки независимых
файлов. Программная документация получается удивительно плохой, а ее
сопровождение — и того хуже. Вносимые в программу изменения не получают
быстрого, точного и обязательного отражения в документе.
Я полагаю, что правильным решением должно быть слияние файлов: включение
документации в исходный текст программы. Это одновременно и сильный
побудительный мотив к должному сопровождению, и гарантия того, что
документация всегда будет под рукой у пользователя. Такие программы называют
самодокументирующимися.
Очевидно, при этом неудобно, хотя и возможно, включать блок-схемы, если в этом
есть необходимость. Но, приняв во внимание анахронизм блок-схем и использование
преимущественно языков высокого уровня, становится возможным объединить
программу с документацией.
Использование исходного кода программы в качестве носителя документации влечет
некоторые ограничения. С другой стороны, непосредственный доступ читателя
документации к каждой строке программы открывает возможность для новых
технологий. Пришло время разработать радикально новые подходы и методы
составления программной документации.
В качестве важнейшей цели мы должны попытаться предельно уменьшить груз
документации — груз, с которым ни мы, ни наши предшественники толком не
справились.