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

Реймонд Эрик Стивен

6.2.1. Дзэн прозрачности

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

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

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

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

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

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

В главе 4 дан критический обзор объектно-ориентированного программирования, который, вероятно, несколько шокировал программистов, выросших на ОО-учении 90-х годов прошлого века. Конструкции, основанные на объектно-ориентированных языках программирования, не должны быть чрезмерно сложными, но, как отмечалось в главе 4, часто являются таковыми. Слишком многие ОО-конструкции являются хитросплетениями отношений "является" и "содержит" (is-a и has-a) или характеризуются большими связующими уровнями, в которых многие объекты, кажется, существуют только для того, чтобы занимать место в неприступной пирамиде абстракций. Подобные конструкции противоположны прозрачным, они печально известны как неясные и сложные для отладки.

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

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

6.2.2. Программирование, обеспечивающее прозрачность и воспринимаемость

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

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

• Какова максимальная глубина иерархии вызова процедур? Т.е., не считая рекурсии, сколько уровней вызова человеку придется мысленно смоделировать, для того чтобы понять работу кода? Совет: будьте предельно внимательны, та как наличие более четырех уровней явно свидетельствует о возникшей проблеме.

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

62

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

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

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

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

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

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

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

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

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

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

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

– v

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