Искусство программирования для Unix - Эрик Реймонд

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

• Являются ли вызовы функций в API-интерфейсах индивидуально ортогональными, или имеют ли они чрезмерное количество "магических" флагов и битов режима, которые заставляют один вызов выполнять несколько задач? Полный отказ от флагов режима может привести к созданию загроможденного API-интерфейса с чрезмерным количеством почти идентичных функций. Но еще шире распространена противоположная ошибка (множество флагов режима, которые легко забыть или перепутать).

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

• Существует ли в программе четкое, точное соответствие между структурами данных или классами и объектами реального мира, которые представлены ими?

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

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

• Каково количество "магических" чисел (необъяснимых констант) в коде? Просто ли обнаружить ограничения реализации (такие как критические размеры буферов) путем просмотра?

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

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

6.2.3. Прозрачность и предотвращение избыточной защищенности

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

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

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

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

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

6.2.4. Прозрачность и редактируемые формы представления

Другой идеей, возникающей в связи с данными примерами, является значение программ, которые переводят проблему из области, где обеспечить прозрачность трудно, в область, где реализовать ее легко. Программы audacity, sng(1) и пара tic(1)/infocmp(1) обладают данным свойством. Объекты, которыми они манипулируют, "не удобны для зрения и рук". Аудиофайлы не являются визуальными объектами, а редактировать блоки PNG-аннотаций сложно, несмотря на то, что PNG-изображения видимы. Все три приложения превращают изменение своих двоичных файловых форматов в проблему, решить которую пользователи вполне могут благодаря своей интуиции и навыкам, полученным из повседневного опыта.

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

Все преимущества текстовых форматов файлов данных, рассмотренных в главе 5, также применимы к текстовым форматам, которые создаются утилитами sng(1), infocmp(1) и им подобными. Одной важной прикладной задачей для sng(1) является автоматическое создание PNG-аннотаций с помощью сценариев. Такие сценарии просты в написании, поскольку существует утилита sng(1).

Каждый раз при разработке конструкции, которая затрагивает редактирование некоторого вида сложного двоичного объекта, традиция Unix, прежде всего, заставляет разработчика выяснить, возможно ли написать средство, аналогичное sng(1) или паре tic(1)/infocmp(1), которое способно без потерь выполнять преобразование данных в редактируемый текстовый формат и обратно. Устоявшегося термина для программ такого рода не существует, но в данной книге они называются текстуализаторами (textualizers).

Если двоичный объект создается динамически или имеет очень большие размеры, то может быть непрактично или невозможно охватить текстуализатором всю его структуру. В таком случае эквивалентная задача состоит в написании браузера. Принципиальным примером является утилита fsdb(1), отладчик файловой системы, поддерживаемый в различных Unix-системах. Существует Linux-эквивалент, который называется debugfs(1). Двумя другими примерами является утилита psql(1), используемая для просмотра баз данных PostgreSQL, и программа smbclient(1), которую можно применять для опроса Windows-ресурсов на Linux-машине, оснащенной пакетом SAMBA. Все эти утилиты являются простыми CLI-программами, которыми можно управлять с помощью сценариев и тестовых программ.

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

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

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

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

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