Искусство программирования для Unix полностью

fetchmail: SMTP>. (EOM)

fetchmail: SMTP< 250 2.0.0 gB9ffWo08245 Message accepted for delivery flushed

fetchmail: IMAP> A0008 STORE 2 +FLAGS (\Seen \Deleted)

fetchmail: IMAP< * 2 FETCH (FLAGS (\Recent \Seen \Deleted))

fetchmail: IMAP< A0008 OK STORE completed

fetchmail: IMAP> A0009 EXPUNGE

fetchmail: IMAP< * 2 EXPUNGE

fetchmail: IMAP< * 1 EXISTS

fetchmail: IMAP< * 0 RECENT

fetchmail: IMAP< A0009 OK Expunged 1 messages fetchmail: IMAP> A0010 LOGOUT

fetchmail: IMAP< * BYE hurkle IMAP4revl server terminating connection

fetchmail: IMAP< A0010 OK LOGOUT completed

fetchmail: 6.1.0 querying hurkle.thyrsus.com (protocol IMAP)

at Mon, 09 Dec 2002 08:41:42 -0500: poll completed fetchmail: SMTP> QUIT

fetchmail: SMTP< 221 2.0.0 snark.thyrsus.com closing connection fetchmail: normal termination, status 0

Параметр -v делает программу fetchmail воспринимаемой (предоставляя возможность просмотреть обмен данными протокола). Это чрезвычайно полезно. Я посчитал это настолько важным, что написал специальный код для маскирования паролей учетных записей в распечатках транзакций, выполненных благодаря параметру -V, так чтобы распечатки можно было отправлять без необходимости редактирования секретной информации в них.

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

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

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

Программа GCC, GNU С-компилятор, применяемый в большинстве современных Unix-систем, возможно, наилучшим образом демонстрирует преимущества проектирования с учетом прозрачности. Программа GCC организована как последовательность стадий обработки, связанных вместе программой драйвера: стадии препроцессора, синтаксического анализатора, генератора кода, ассемблера и линкера.

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

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