Программист-прагматик

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

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

Что такое простой текст?

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

Читатель и понятия не имеет, каков смысл значения 467аЬе. Лучше сделать его понятным:

Простой текст вовсе не означает, что в нем отсутствует структура; яркими примерами простого текста с четко определенной структурой являются форматы XML, SGML и HTML. С простым текстом можно проделывать все те же операции, что и с двоичным форматом, включая управление версиями.

Простой текст имеет тенденцию находиться на более высоком уровне, чем простая двоичная кодировка, обычно возникающая непосредственно из реализации. Предположим, вам нужно хранить свойство под названием usesjnenus, которое может принимать значение TRUE или FALSE. Используя простой текст, вы можете записать это следующим образом:

А теперь сравните это с 0010010101110101.

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

Недостатки

Простой текст обладает двумя основными недостатками: (1) при хранении он может занимать больше места, чем сжатый двоичный формат, и (2) с точки зрения вычислений интерпретация и обработка файла с простым текстом может проводиться медленнее.

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

Но и в этих ситуациях допустимо сохранять метаданные, описывающие исходные данные, в формате простого текста (см. раздел «Метапрограммирование»).

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

Преимущества простого текста

Поскольку «больше» и «медленнее» – не самые популярные требования, предъявляемые пользователями, то зачем вообще нужен простой текст? Каковы его преимущества?

• Гарантия того, что данные не устареют

• Более короткий путь к цели

• Более простое тестирование

Форматы данных, которые может воспринять человек, и самодокументированные данные переживут все другие форматы данных и приложения, их породившие. И точка.

На протяжении всего срока жизни данных вы сможете пользоваться ими и в перспективе – еще долго после того, как прикладная программа, их породившая, прекратит свое существование.

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

Рассмотрим файл данных из некой унаследованной [17] системы. Вы обладаете скудной информацией о прикладной программе, которая создала этот файл; эта информация сводится к тому, что она поддерживала список номеров SSN (Social Security Number – номер социального страхования) клиентов, которые вам необходимо найти и извлечь из архива. Среди данных вы видите:

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

Но представим, что вместо этого файл отформатирован следующим образом:

Не так-то легко распознать значение чисел, представленное в таком виде. В этом и состоит разница между воспринимаемым человеком и понятным человеку. Но и от обозначения FIELD10 толку будет немного. А нечто вроде:

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

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

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

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

Предположим, что вы развертываете крупномасштабное приложение со сложным конфигурационным файлом, характерным для конкретного местоположения (на ум сразу приходит sendmail). Если этот файл представляет собой простой текст, то его можно подчинить системе управления исходными текстами (см. «Управление исходным текстом»), и вы автоматически сохраняете хронологию всех изменений. Инструментальные средства сравнения файлов, такие как diff и fc, позволяют сразу увидеть, какие изменения были внесены, тогда как sum позволяет генерировать контрольную сумму для отслеживания файла на предмет случайных (или злонамеренных) модификаций.

Если вы используете простой текст при создании синтетических данных для запуска системных тестов, то добавление, обновление или модификация тестовых данных (без привлечения каких-либо специальных инструментальных средств) не представляет особого труда. Аналогично, результат регрессионного тестирования в виде простого текста может быть проанализирован тривиальным образом (например, с помощью программы diff) или более тщательно с помощью языков Perl, Python и при помощи некоторых других средств написания сценариев (скриптов).

Подводим итог

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

• Управление исходным текстом

• Генераторы исходного текста

• Метапрограммирование

• Доски объявлений

• Вездесущая автоматизация

• Все эти сочинения

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

1. Преобразуйте этот формат в формат простого текста, используя XML.

2. Для каждой из версий добавьте новое поле переменной длины под названием directions, в котором вы могли бы вводить указания, как подъехать к дому каждого адресата.

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

Каждому столяру нужен хороший, солидный, надежный верстак – место, расположенное на удобной для столяра высоте, на котором он в ходе своей работы мог бы разместить предметы труда. Верстак становится центром мастерской, столяр возвращается к нему снова и снова, придавая форму материалу.

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

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

Ответ прост: «Нет». Графические интерфейсы сами по себе прекрасны, и с их помощью многие простые операции выполняются быстрее и с большим удобством. Перемещение файлов, чтение сообщений электронной почты с кодировкой MIME и набор текстов писем – это все то, что вы хотели бы осуществлять в графической среде. Но если выделаете всю работу, используя графический интерфейс, то используете далеко не все возможности, предоставляемые операционной системой. И вам не удастся автоматизировать обычные задачи или использовать доступные инструментальные средства в полную силу. И вы не сможете комбинировать свои средства для создания специализированных макроинструментов. Преимуществом графического интерфейса пользователя является принцип WYSIWYG – что видишь, то и получаешь. Недостатком графического интерфейса можно назвать принцип WYSIAYG – получаешь только то, что видишь.

Графические среды обычно ограничены возможностями, заложенными в них разработчиками. Если вам необходимо выйти за пределы модели, созданной разработчиком, то обычно фортуна отворачивается от вас, однако чаще всего вам все-таки приходится выходить за пределы модели. Прагматики не просто либо «рубят» текст, либо разрабатывают объектные модели, либо пишут документацию или автоматизируют процесс сборки – они делают все вышеперечисленное. Сфера применения любого конкретного инструмента обычно ограничена задачами, решения которых от него ожидают. Предположим, возникла необходимость в интеграции препроцессора исходного текста с ИСР (при реализации концепции «проектирования по контракту», многопроцессных директив, и т. п.). Если разработчик ИСР явно не предусмотрел наличия в ней специальных средств, то вы не справитесь с решением задачи интеграции.

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

Исповедуя прагматизм, вы постоянно будете испытывать потребность в осуществлении операций ad hoc (лат. для конкретного случая. – Прим. пер.) – это и есть те самые случаи, когда графический интерфейс может оказаться неприменимым. Командная строка может стать лучшим решением, если необходимо быстро скомбинировать несколько команд при выполнении запроса или иного задания. Ниже приводится несколько примеров.

Найти все файлы типа *.с, модифицированные позже, чем ваш Makefile.

Командная строка:

find. -name *.с' – newer Makefile – print

Графический интерфейс:

Откройте Проводник Windows, перейдите в нужный каталог, щелкните по Makefile и отметьте для себя время модификации данного файла. Затем войдите в меню Tools, выберите пункт Find, и введите *.с в строку, указывающую параметры имени файла. Затем перейдите в поле даты, и введите дату, которую вы вначале отметили для Makefile. Затем нажмите ОК.

Создать архив типа zip/tar моего исходного текста.

Командная строка:

zip archive.zip *.h *.с или

tar cvf archive.tar \h *.c

Графический интерфейс:

Запустите утилиту архивирования (например, условно-бесилатную программу WinZip [URL 41], выберите пункт Create New Archive, введите его имя, выберите исходный каталог в диалоге Add, задайте фильтр «*.с», щелкните по пункту «Add», задайте фильтр «*.h», щелкните по пункту «Add», затем закройте архив.

Какие файлы Java не были изменены за последнюю неделю?

Командная строка:

find . Name *.java' – mtime + 7 – print

Графический интерфейс:

Щелкните и переместитесь к пункту «Find files», щелкните по полю «Named» и введите в него «*.java», выберите пункт «Date Modified». Затем выберите пункт «Between». Затем щелкните по начальной дате и введите начальную дату начала проекта. Щелкните по конечной дате и введите дату, которая была неделю назад (убедитесь, что календарь находится под рукой). Затем щелкните по пункту «Find Now».

Какие из данных файлов используют библиотеки awt?

Командная строка:

find . -name *.java' – mtime +7 – print | xargs grep 'java.awt'

Графический интерфейс:

Загрузите каждый файл в списке из предыдущего примера в редактор и проведите поиск строки java.awt. Напишите имя каждого файла, содержащего совпадение.

Ясно, что этот список может быть продолжен. Строчные команды могут быть непонятными и компактными, но они обладают мощностью и краткостью. И поскольку они могут сводиться в файлы сценариев (или командные файлы в системе Windows), то вы можете создавать последовательности команд для автоматизации часто выполняемых процедур.

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

grep «import' *.java |

sed -e's/.'import //' – e's/;.$//' |

sort -u >list

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

Утилиты оболочек и системы Windows

Хотя командные оболочки, поставляемые с системами Windows постепенно улучшаются, утилиты командной строки Windows все еще уступают их двойникам в Unix. Однако все не так плохо.

Фирма Cygnus Solutions разработала пакет под названием Cygwin [URL 31]. Помимо обеспечения слоя совместимости Unix для Windows, Cygwin поставляется вместе с коллекцией более чем 120 утилит Unix, включая такие бестселлеры, как Is, grep и find. Утилиты и библиотеки могут загружаться и использоваться бесплатно, но обязательно прочтите их лицензию [18]. Программа Cygwin распространяется вместе с оболочкой Bash.

Нам нравится, что высококачественные инструментальные средства Unix работают в среде Windows, и мы пользуемся ими ежедневно. Однако надо иметь в виду, что существуют проблемы интеграции. Эти утилиты (в отличие от их двойников, работающих в MS-DOS) чувствительны к регистру в именах файлов, так что команда ls a*.bat не сможет найти файл AUTOEXEC.BAT. Вы можете также столкнуться с проблемами, вызванными файлами, чьи имена содержат пробелы, и с различиями в разделителях пути. Наконец, есть проблемы, связанные с запуском из-под оболочек Unix программ MS-DOS, в которых ожидается наличие аргументов в стиле MS-DOS. Например, утилиты Java, написанные фирмой JavaSoft, используют двоеточие (как и в их разделителе CLASSPATH при работе в среде Unix), а при работе в MS-DOS используют точку с запятой. В результате сценарий Bash или ksh, запускаемый в окне Unix, будет работать также и в Windows, но командная строка, передаваемая ею Java, будет интерпретироваться некорректно.

В качестве альтернативы Дэвид Корн (автор известной оболочки Korn) создал пакет под названием UWIN. Он предназначен для тех же целей, что и продукт Cygwin – это среда разработчика Unix, работающая в Windows. Пакет UWIN распространяется с оболочкой Korn. Коммерческие версии поставляются фирмой Global Technologies, Ltd. [URL 30]. Кроме того, фирма AT&T допускает бесплатную загрузку пакета для оценки его работы и использования в академических учреждениях. Перед его использованием также необходимо прочесть лицензию.

И наконец, Том Кристиансен (во время написания книги) компонует Perl Power Tools, пытаясь в сжатом виде реализовать все известные утилиты Unix на языке Perl [URL 32].

• Вездесущая автоматизация

• Существуют ли операции, которые в данное время вам приходится выполнять вручную, работая в графической среде? Приходилось ли вам когда-либо сочинять для коллег по работе инструкции, состоящие из отдельных пунктов типа: «щелкните по этой кнопке», «выберите этот пункт»? Можно ли автоматизировать данный процесс?

• При переходе к новой операционной среде обратите особое внимание на то, ка – кие оболочки находятся в вашем распоряжении. Посмотрите, можете ли вы перенести в новую среду оболочку, с которой работаете в данный момент.

• Изучите возможные альтернативы оболочке, используемой вами в настоящее время. Если вы сталкиваетесь с проблемой, которую невозможно решить средствами имеющейся у вас оболочки, может быть, альтернативная оболочка проявит себя лучше?

Выше уже говорилось об инструментах, которые являются продолжением вашей руки. Это положение применимо к текстовым редакторам в большей степени, нежели к любому другому инструменту. Необходимо, чтобы вы затрачивали минимальные усилия на обработку текста, поскольку последний является основным «сырьем» при программировании. Рассмотрим некоторые общие характеристики и функции, которые помогают использовать ваш текстовый редактор с максимальным КПД.

Один-единственный редактор

Мы полагаем, что лучше овладеть одним-единственным редактором, но в совершенстве, и использовать его для решения всех задач, связанных с редактированием: работа с текстом программ, документацией, записками, системное администрирование и т. д. Не имея под рукой хотя бы одного редактора, можно оказаться в ситуации, аналогичной вавилонскому смешению языков, но уже на современный манер. При написании текстов программ может понадобиться встроенный редактор ИСР (для каждого языка), для создания документации – универсальный офисный редактор, а может быть, и еще один встроенный редактор для отправки сообщений по электронной почте. Различаться могут даже клавиатурные команды, используемые вами для редактирования командных строк в оболочке [19]. Трудно быть экспертом в любой из этих программных сред, если в каждой из них имеется свой набор команд и соглашений при редактировании.

Но экспертом быть необходимо. Мало набирать символы построчно и использовать мышь для вырезания и вставки фрагментов. Работая подобным образом, вы не достигнете того уровня производительности, который возможен при наличии мощного текстового редактора. Десятикратное нажатие клавиши <- или BACKSPACE для перемещения курсора влево к началу строки не столь эффективно, как простая клавиатурная команда, например Ctrl+A, Home или 0.

Выберите какой-либо редактор, тщательно изучите его и используйте во всех задачах, связанных с редактированием текста. Если вы пользуетесь одним редактором (или набором функциональных клавиш) для всех работ, связанных с редактированием текста, вам не придется останавливаться и обдумывать, как осуществить ту или иную обработку текста: нажатие нужных клавиш становится рефлексом, редактор – продолжением вашей руки: клавиши поют свою песню, перемещаясь по тексту сквозь череду мыслей. Это и есть цель!

Убедитесь, что выбранный вами редактор поддерживается всеми платформами, с которыми вы работаете. Редакторы Emacs, vi, CRISP, Brief и ряд других поддерживаются несколькими платформами, часто в двух версиях – в графической и неграфической (текстовый режим).

Средства редактирования

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

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

• Расширяемость. Редактор не должен устаревать только потому, что появляется новый язык программирования. Он должен обладать способностью интегрироваться в любую компиляторную среду, используемую вами в данный момент. Вы должны «обучить» его нюансам любого нового языка программирования или текстового формата (XML, HTML версии 9, и т. д.).

• Программируемость. Вы должны располагать возможностью программирования редактора для осуществления сложных многоступенчатых операций. Это может осуществляться при помощи макросов или встроенного языка программирования сценариев (к примеру, редактор Emacs использует вариант языка Lisp).

В дополнение к этому многие редакторы поддерживают средства, которые свойственны конкретному языку программирования:

• Выделение синтаксических конструкций

• Автоматическое завершение

• Автоматический отступ

• Библиотека исходных стандартных текстов или документов

• Принудительная справка, выдаваемая системой

• Средства, подобные ИСР (компиляция, отладка и т. д.).

Рис. 3.1. Упорядочение строк в редакторе

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

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

Производительность

Удивительно, но многие люди, с которыми нам довелось встречаться, используют для редактирования исходных текстов программ утилиту notepad, входящую в систему Windows. Это сильно напоминает использование чайной ложечки вместо совковой лопаты – примитивный набор текста и использование основных команд («вырезать-вставить»), активизируемых с помощью мыши, явно недостаточны

Какие же процедуры могут потребовать от вас большего, чем примитивные действия, описанные выше?

Начнем с перемещения курсора. Некоторые клавиатурные команды, перемещающие вас по словам, строкам, блокам или функциям, являются более эффективными по сравнению с повторным нажатием одной и той же клавиши, перемещающей курсор от символа к символу или от строки к строке.

Предположим, что вы пишете программу на языке Java. Вам нравится поддерживать ваши операторы import в алфавитном порядке, но кто-то чужой зарегистрировал несколько файлов, не отвечающих этому стандарту Вы хотели бы пробежать по нескольким файлам и упорядочить некоторую их часть. Это легко сделать при работе с редакторами типа vi и Emacs (см. рис. 3.1). А попробуйте сделать то же самое в редакторе notepad!

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

• Наименование создаваемого класса или модуля (определенного из имени файла)

• Ваше имя и/или знак авторского права

• «Скелеты» конструкций на данном языке (например, описания конструктора или деструктора)

Другим полезным средством является автоматический отступ. В нужный момент редактор автоматически делает отступы (например, при вводе открывающей скобки), и не нужно проделывать ту же операцию вручную (используя пробел или табуляцию). Преимуществом этого средства является то, что вы можете использовать редактор для обеспечения постоянства стиля отступа в вашем проекте [20].

Куда же направиться?

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

Если это похоже на вас:

Тогда задумайтесь о следующем:

Я пользуюсь только основными средствами многих разнообразных редакторов.

Выберите мощный редактор и изучите его хорошенько.

У меня есть любимый редактор, но я не использую все его средства

Изучите эти средства. Сократите число используемых клавиатурных команд.

У меня есть любимый редактор и я использую его везде, где только возможно

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

Я думаю, что вы говорите ерунду. Notepad является самым лучшим редактором из когда-либо созданных

Пока вы счастливы и продуктивны, используйте notepad! Но если вы окажетесь подвержены чувству «редакторской зависти», возможно, что вы и пересмотрите свою позицию

Какой же редактор выбрать?

Советуем освоить приличный редактор, но какой же именно? Уклонимся от ответа на этот вопрос: выбор редактора является личным делом каждого (некоторые даже скажут, что выбор редактора связан с вероисповеданием!). В приложении А приведен список популярных редакторов и мест, откуда их можно загрузить.

• Некоторые редакторы используют полномасштабные языки для настройки и создания сценариев. Например, в редакторе Emacs используется язык программирования Lisp. В качестве одного из новых языков, который вы наметили изучить в этом году, изучите язык, используемый вашим редактором. Разработайте набор макросов (или эквивалентных им средств) для всех операций, которые вам приходится осуществлять повторно.

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

Одним из наиболее важных свойств, которые интересуют нас в интерфейсе пользователя, является кнопка UNDO – единственная кнопка, которая прощает нам наши ошибки. Еще лучше, если графическая среда поддерживает многоуровневый откат и повтор так, что можно вернуться назади восстановить статус-кво, существовавший за несколько минут до этого. Но как быть, если ошибка произошла на прошлой неделе и за прошедшее время компьютер включался и выключался раз десять? Это и является одним из многих преимуществ системы управления исходным текстом программ: она является своего рода гигантской клавишей UNDO – машиной времени, работающей в масштабах проекта, которая способна вернуть вас к безмятежным дням на прошлой неделе, когда программа реально компилировалась и запускалась.

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

Но система управления исходным текстом (английская аббревиатура SCCS) [21]дает много больше, чем просто отмену ошибочных действий. Хорошая система позволяет отслеживать изменения и дает ответы на характерные вопросы: «Кто внес изменения в данную строку текста? В чем состоит разница между версией, существующей на данный момент, и версией, существовавшей на прошлой неделе? Сколько строк текста программы были изменены в данной версии? Какие файлы изменяются чаще всего?» Подобная информация бесценна при отслеживании ошибок, аудите, оценке производительности и качества.

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

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

Системы управления могут сохранять поддерживаемые ими файлы в централизованной БД проекта – лучшем кандидате на архивирование.

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

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

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

Механизм сборки проекта может автоматически извлекать последнюю версию исходного текста из централизованной БД. Этот механизм может запускаться среди ночи, после того как все сотрудники (будем надеяться на это) уйдут домой. Вы можете автоматически прогонять регрессионные тесты для гарантии того, что исходные тексты, созданные в течение рабочего дня, ничего не нарушили. Автоматизация сборки обеспечивает согласованность – отсутствуют ручные процедуры, и вам не нужно, чтобы разработчики помнили о копировании созданного ими текста в специальную сборочную область.

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

Команда, в которой я работаю, не использует систему управления исходным текстом

Как же им не стыдно! Звучит как перспектива провести очередную Реформацию! Однако, пока вы дождетесь, когда они увидят свет во тьме, стоит попробовать внедрить свою, частную систему управления. Воспользуйтесь одним из бесплатных инструментальных средств, указанных в приложении А, и обратите особое внимание на то, чтобы результаты вашей личной работы были надежно сохранены в централизованной БД. Хоть это и может показаться двойной работой, мы с уверенностью можем сказать, что эта процедура сбережет ваши нервы (и сэкономит деньги, отпущенные на проект) в тот момент, когда вам впервые придется ответить на вопросы типа «Что ты натворил с модулем xyz?» и «Кто разрушил сборку?» Подобный подход поможет вам убедить руководство в том, что система управления исходным текстом действительно работает.

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

Программы управления исходным текстом

В приложении А приведены интернет-ссылки (URL) на типичные системы управления исходным текстом – некоторые из них являются коммерческими продуктами, другие же распространяются бесплатно. Имеются и другие программные продукты – обратите внимание на ссылки на часто задаваемые вопросы (FAQ) по управлению конфигурацией.

• Ортогональность

• Преимущество простого текста

• Все эти сочинения

• Даже если у вас нет возможности использовать систему управления исходным текстом на работе, установите RCS или CVS на личный компьютер. Воспользуйтесь ей для управления вашими домашними проектами, документами, которые вы составляете, и (возможно) изменениями в конфигурации самой компьютерной системы.

• Обратите внимание на некоторые из проектов с открытыми исходными текстами, архивы которых доступны в сети Интернет (например, Mozilla [URL 51], KDE[URL 54] и Gimp [URL 55]). Каким образом вы получаете обновления исходного текста? Как вы вносите изменения – сам проект регулирует доступ, или же разрешает внесение изменений?

Английское слово bug (ошибка) используется для описания «объекта, вызывающего ужас» уже начиная с XIV в. Контр-адмирал д-р Грэйс Хоппер (создатель языка COBOL) оказался первым, кто наблюдал компьютерного «жучка», буквально – моли, попавшей в одно из электромеханических реле, из которых состояли первые вычислительные системы. Когда техника попросили объяснить, почему машина ведет себя не так, как надо, он сообщил, что в системе «завелся жучок», и в соответствии со своими должностными обязанностями приклеил его клейкой лентой вместе с крылышками и всем остальным в рабочий журнал.

К сожалению, мы до сих пор встречаемся с «жучками» в системе, хотя и не из рода перепончатокрылых. Но значение этого слова, принятое в XIV в. – привидение – возможно более применимо сейчас, нежели тогда. Изъяны в программном обеспечении проявляют себя по-разному – от превратно истолкованных требований до ошибок в написании исходных текстов. К сожалению, возможности современных компьютерных систем все еще ограничены исполнением только того, что мы им прикажем, а не обязательно того, что мы хотим, чтобы они сделали.

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

Психология процесса отладки

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

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

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

На самом деле, не важно, кто виноват в ошибке – вы или кто-то другой. Это все равно остается вашей проблемой.

Умонастроение отладки

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

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

Если ваша первая реакция после обнаружения ошибки или просмотра отчета об ошибках сводится к восклицанию «Это невозможно!», то вы явно ошиблись. Не стоит тратить ни одного нейрона на цепочку умозаключений, начинающуюся с фразы «Но этого не может быть!», потому что совершенно ясно, что может, и это произошло.

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

С чего начать?

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

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

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

Однажды один из авторов книги (Энди Хант) работал над большим графическим приложением. Дело уже шло к выпуску готовой версии, когда тестировщики сообщили о том, что приложение «падало» всякий раз, когда они проводили черту при помощи конкретной кисти. Программист начал оспаривать это утверждение, говоря о том, что все в порядке: он сам пытался выполнять аналогичную прорисовку, и все работало превосходно. Обмен любезностями продолжался в течение нескольких дней, когда напряженность вдруг резко возросла.

В конце концов все собрались в одной комнате. Тестировщик выбрал нужный инструмент (кисть) и провел черту, из ВЕРХНЕГО ПРАВОГО угла к НИЖНЕМУ ЛЕВОМУ. Приложение «упало»! Программист тихонько охнул, а затем виновато проблеял, что при тестировании он проводил черту только из НИЖНЕГО ЛЕВОГО угла к ВЕРХНЕМУ ПРАВОМУ, и при этом ошибка никак не выявлялась.

В этой истории есть два момента, заслуживающих внимания:

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

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

Стратегии отладки

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

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

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

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

Другие идеи, касающиеся вышеприведенного, представлены в разделе «Вездесущая автоматизация».

Пристальный взгляд на данные, с которыми работает программа, во многих случаях является лучшим способом увидеть то, что же она делает (или собирается делать). Простейшим примером этого является прямолинейный подход типа «переменная = значение», который может быть реализован в виде печатного текста или в виде полей диалогового окна (списка) графического интерфейса.

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

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

В отладчике DDD имеются некоторые средства визуализации, которые распространяются бесплатно (см. [URL 19]). Интересно заметить, что отладчик DDD работает со многими языками, включая Ada, С, С++, Fortran, Java, Modula, Pascal, Perl и Python (явно ортогональная конструкция).

Рис. 3.2. Пример отладочной схемы циркулярного связанного списка. Стрелки указывают на узлы.

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

Операторы трассировки представляют собой небольшие диагностические сообщения, которые выводятся на экран или в файл и говорят о том, что «это здесь» и «х = 2». Это примитивная методика, сравнимая с отладчиками в стиле ИСР, но она особенно эффективна при диагностировании некоторых классов ошибок, с которыми отладчики справиться не могут. Трассировка имеет большое значение в любой системе, где время само по себе является фактором: в одновременных процессах, системах реального времени и приложениях, основанных на событиях.

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

Трассировочные сообщения должны быть представлены в регулярном, согласованном формате; возможно, вам захочется провести их синтаксический анализ в автоматическом режиме. Например, если вам необходимо отследить утечку ресурсов (несбалансированные операции открытия и закрытия файлов), вы можете трассировать каждый из операторов open и close в файле журнала. Обрабатывая файл журнала с помощью программы на языке Perl, вы легко обнаружите, где встречался оператор-нарушитель open.

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

Похоже, что кто-то указал адрес поверх счетчика цикла. Теперь, мы знаем где искать.

Очень простая, но весьма полезная методика поиска причины проблемы, состоит в том, чтобы разъяснить ее кому-либо. Ваш собеседник должен заглядывать через ваше плечо на экран монитора и время от времени утвердительно кивать головой (подобно резиновому утенку, ныряющему и выныривающему в ванне). Ему не нужно говорить ни слова; простое, последовательное объяснение того, что же должна делать ваша программа, часто приводит к тому, что проблема выпрыгивает из монитора и объявляет во всеуслышанье: «А вот и я!» [22].

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

В большинстве проектов отлаживаемая вами программа может представлять собой смесь прикладных программ, написанных лично вами и другими сотрудниками вашей проектной команды, а также программные продукты, созданные независимыми производителями (база данных, обеспечение связи, графические библиотеки, специализированные протоколы связи или алгоритмы, и т. д.) и платформенное окружение (операционная система, системные библиотеки и компиляторы).

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

Однажды мы работали над проектом, и старший инженер был уверен, что в системе Solaris имелось нарушение системного вызова select. Никакие убеждения или логические построения не могли изменить сложившегося у него мнения (тот факт, что все другие сетевые приложения работали прекрасно, не принимался во внимание). Неделями он составлял программы обхода этого вызова, которые, по какой-то странной причине, не способствовали решению проблемы. И когда в конце концов он был вынужден сесть за стол и прочесть документацию по вызову select, он обнаружил, в чем заключалась проблема, и исправил ее за несколько минут. Теперь мы используем выражение «вызов select нарушен» как деликатное напоминание, в тех случаях, когда один из нас начинает обвинять систему в наличии ошибки, которая, скорее всего, является его собственной.

Помните: увидев следы копыт, думайте о лошадях, а не о зебрах. Скорее всего, операционная система не нарушена. Да и база данных находится в прекрасном состоянии.

Если вы «внесли всего одно изменение», и система перестала работать, то, скорее всего, именно оно, прямо или косвенно, несет ответственность за случившееся, каким бы притянутым за уши ни казалось это утверждение. Иногда то, что изменяется, находится вне вашего управления: новые версии операционной системы, компилятора, базы данных или программы независимых производителей могут вызывать проблемы и с изначально корректной программой. В ней могут обнаружиться новые ошибки. Ошибки, которые были устранены с помощью программы обхода, преодолевают действие этой программы. Если изменяются API, то изменяются и функциональные возможности; короче говоря, это уже новая история, и вам надлежит провести повторное тестирование системы в новых сложившихся условиях. Так что не спускайте глаз с графика выполнения проекта, если собираетесь провести модернизацию; может быть, придется подождать до выпуска новой версии.

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

Элемент удивления

Если ошибка вызвала у вас удивление (до того, что вы еле слышно бормочете «Этого не может быть»), стоит провести переоценку истин, дорогих вашему сердцу. А все ли граничные условия вы протестировали в подпрограмме связанного списка – той, которую вы считали непробиваемой и которая, по всей вероятности, не могла стать причиной этой ошибки? А другой фрагмент текста программы, который вы использовали в течение нескольких лет, – не мог ли он все еще таить в себе ошибку?

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

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

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

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

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

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

Проделайте все это, и наверняка в следующий раз вы будете избавлены от подобных сюрпризов.

Контрольные вопросы при отладке

• Является ли проблема прямым результатом фундаментальной ошибки или просто ее признаком?

• Ошибка действительно «сидит» в компиляторе? В операционной системе? Или в вашей собственной программе?

• Если бы вам пришлось подробно объяснить вашему коллеге, в чем состоит проблема, что бы вы ему сказали?

• Если подозрительная программа проходит модульное тестирование, то является ли оно достаточно полным? Что произойдет, если вы прогоняете модульный тест с реальными данными?

• Существуют ли условия, вызвавшие данную ошибку, где-либо еще в системе?

• Программирование на основе утверждений

• Программирование в расчете на совпадение

• Вездесущая автоматизация

• Безжалостное тестирование

• Отладка сама по себе является вопросом.

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

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

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

Существует два основных типа генераторов текста:

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

2. Активные генераторы текста используются всякий раз, когда возникает необходимость в результатах их работы. Этот результат создается по принципу «выбросить и забыть» – он всегда может быть воспроизведен с помощью генератора текста. Зачастую активные генераторы считывают некоторую форму сценария или управляющего файла для получения конечного результата.

Пассивные генераторы

Пассивные генераторы текста экономят время, необходимое на набор текста. Как только результат получен, он становится полностью приспособленным для использования в качестве исходного файла в данном проекте; он должен быть отредактирован, скомпилирован и передан системе управления исходным текстом, как и любой другой файл. О его происхождении никто и не вспомнит. Пассивные генераторы текста применяются во многих случаях:

• Создание новых исходных файлов. Пассивный генератор текста может создавать шаблоны, директивы управления исходным текстом, сведения об авторских правах и стандартные блоки комментариев для каждого нового файла в некотором проекте. Мы настроили наши редакторы на выполнение этого действия всякий раз при создании нового файла: при редактировании новой программы на языке Java в новом буфере редактора автоматически окажутся уже заполненные блок комментариев, директива пакета и описание структурного класса.

• Осуществление двоичных преобразований в языках программирования. Мы начали писать эту книгу, используя систему troff, но после пятнадцатого раздела перешли на LaTeX. Мы написали генератор текста, который считывал исходный текст из troff и преобразовывали его в формат LATЈX. Точность составила 90 %; остальное мы делали вручную. Это является интересной особенностью пассивных генераторов текста: они не должны отличаться абсолютной точностью. Вы выбираете, какое усилие необходимо вложить в генератор, в сравнении с энергией, которую вы тратите на устранение ошибок в выходной информации.

• Создание таблиц поиска и других ресурсов, вычисление которых является дорогой операцией. Вместо того, чтобы вычислять тригонометрические функции, во многих старых графических системах использовались таблицы синусов и косинусов. Обычно эти таблицы создавались пассивным генератором текста и затем копировались в исходный текст программы.

Активные генераторы текста

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

Когда бы вам ни приходилось организовывать совместную работу двух совершенно разных сред, стоит подумать об использовании активных генераторов текста.

Допустим, вы разрабатываете приложение БД. В этом случае вы имеете дело с двумя средами – базой данных и языком программирования, который используется для доступа к БД. У вас есть схема, и вам необходимо определить низкоуровневые конструкции, отражающие компоновку определенных таблиц БД. Вы могли бы просто запрограммировать их напрямую, но при этом нарушается принцип DRY: знание схемы было бы выражено дважды. Если схема меняется, вам необходимо помнить и о соответствующем изменении текста программы. Если из таблицы удаляется столбец, а база текста программы не меняется, то может статься, что ошибка не проявится даже при компиляции. Первый раз вы узнаете об этом во время тестирования, когда начнутся сбои (или же от пользователя).

Рис. 3.3. Активный генератор создает текст программы из схемы базы данных

Альтернативой этому является использование активного генератора текста – берется схема и используется для генерации исходного текста конструкций, как показано на рисунке 3.3. Теперь при любом изменении схемы будет происходить и автоматическое изменение программы, используемой для доступа к ней. При удалении столбца исчезает и соответствующее поле в конструкции, и любая высокоуровневая программа, использующая этот столбец, не пройдет компиляцию. Ошибку удалось заметить во время компиляции, а не в процессе сборки. Конечно, эта схема работает только в том случае, если вы сделаете генерацию текста частью самого процесса сборки [24].

Другим примером слияния сред с помощью генераторов текста является случай, когда в одном и том же приложении использованы различные языки программирования. Для того чтобы общаться, каждой программной базе необходима некоторая общая информация – например, структуры данных, форматы сообщений и имена полей. Вместо того, чтобы дублировать эту информацию, используйте генератор текста. В ряде случаев можно проводить синтаксический анализ информации из исходных файлов на одном языке и использовать ее для генерации текста на другом. Хотя зачастую легче выразить ее более простым, независимым от языка представлением и сгенерировать программу для обоих языков, как показано на рисунке 3.4. Также можно посмотреть ответ к упражнению 13 (см. Приложение В) в качестве примера того, как отделить синтаксический анализ представления плоского файла от генерации текста.

Генераторы текста не должны быть слишком сложными

Весь этот разговор об активном «этом» и пассивном «том», может создать у вас впечатление, что генераторы текста – сложные звери. Им не надо быть сложными. Обычно самой сложной частью является синтаксический анализатор, который обрабатывает входной файл. Не усложняйте входной формат, и генератор текста станет простым. Обратите внимание на ответ к упражнению 13 (см. Приложение В): в реальности генерация текста представляет собой в основном операторы print.

Рис. 3.4. Генерирование теиста из представления, независимого от языка. Строки во входном файле, начинающиеся с буквы М, означают начало определения сообщения, буква F означает строки с определениями полей, а буква Е – конец сообщения.

Генераторы текста не всегда генерируют тексты программ

Хотя многие и примеров, приведенных в данном разделе, демонстрируют тексты программ, которые производят исходные тексты программ, на практике это не всегда так. Вы можете применять генераторы текстов для создания выходного файла в любом формате (HTML, XML, простой текст) – любого текста, который является входной информацией в какой-либо части вашего проекта.

• Пороки дублирования

• Преимущество простого текста

• Злые волшебники

• Вездесущая автоматизация

13. Напишите генератор текста, который обрабатывает входной файл, изображенный на рисунке 3.4, и генерирует выходной файл на двух языках по вашему выбору. Попытайтесь упростить добавление новых языков. (Ответ см. в Приложении В.)