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

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

Дуг Макилрой.

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

• Утилита grep(1) для выбора из файлов строк, соответствующих шаблону, является простым упаковщиком вокруг формальной алгебры шаблонов регулярных выражений (описание приведено в разделе 8.2.2). Если бы данная программа испытывала недостаток в такой последовательной математической модели, то она, вероятно, выглядела бы подобно конструкции первоначального средства старейших Unix-систем, glob(1) — набор узкоспециальных шаблонов, которые невозможно было комбинировать.

• уасс(1) — утилита для создания языковых анализаторов представляет собой тонкий упаковщик вокруг формальной теории грамматики LR(1). Сопутствующая ей утилита, генератор лексических анализаторов lex(1) является подобным тонким упаковщиком вокруг теории недетерминированных конечных автоматов.

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

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

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

4.2.5. Значение освобождения

В начале данной книги упоминалась ссылка на Дзэн об 'особой передаче знаний вне священного писания'. Не следует рассматривать ее как экзотическую, использованную ради стилистического эффекта. Основные понятия Unix всегда отличались свободной, Дзэн-подобной простотой. Данное качество отражено в основополагающих документах Unix, таких как книга 'The С Programming Language' [42], а также доклад CACM 1974 года, в котором Unix была 'представлена миру'. Приведем одну известную цитату из данного документа: '... ограничение побуждает не только к экономии, но и к определенному изяществу дизайна'. Источником этой простоты было стремление думать не о том, как много язык программирования или операционная система способны сделать, а о том, как мало они могут сделать.

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

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

Различные ассоциации между Unix и Дзэн[44] также являются частью традиции Unix, и это не случайно.

4.3. Иерархичность программного обеспечения

В проектировании иерархии функций или объектов определяется два направления. От выбора направления очень зависит иерархическое представление кода.

4.3.1. Сравнение нисходящего и восходящего программирования

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

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

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