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

Идея рефакторинга (refactoring), которая впервые возникла как явная идея школы 'экстремального программирования' (Extreme Programming), тесно связана с ортогональностью. Рефакторинг кода означает изменение его структуры и организации без изменения его видимого поведения. Инженеры программной индустрии, несомненно, решают эту проблему с момента возникновения отрасли, однако определение данной практики и идентификация главного набора методик рефакторинга способствовало решению данного вопроса. Поскольку все это хорошо согласуется с основными концепциями проектирования Unix, Unix-разработчики быстро переняли терминологию и идеи рефакторинга[42].

Основные API-интерфейсы Unix были спроектированы с учетом ортогональности не идеально, но вполне успешно. Например, возможность открытия файла для записи без его блокировки для остальных пользователей принимается как должное; не все операционные системы настолько 'обходительны'. Системные сигналы старой школы (System III) были неортогональными, поскольку получение сигнала имело побочный эффект — происходила переустановка обработчика сигналов в стандартное значение и отключение при получении сигнала. Существуют крупные неортогональные фрагменты, такие как API BSD- сокетов, и очень крупные, такие как графические библиотеки системы X Window.

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

4.2.3. Правило SPOT

В книге 'The Pragmatic Programmer' формулируется правило для одного частного вида ортогональности, который является особенно важным. Это правило 'не повторяйтесь': внутри системы каждый блок знаний должен иметь единственное, недвусмысленное и надежное представление. В данной книге предпочтение отдано совету Брайана Кернигана называть данное правило SPOT-правилом (SPOT, или Single Point Of Truth, — единственная точка истины).

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

Константы, таблицы и метаданные следует объявлять и инициализировать только один раз, а затем импортировать. Всякое дублирование кода является опасным знаком. Сложность приводит к затратам; не следует оплачивать ее дважды.

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

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

• Если документация дублирует данные из кода, то можно ли создать фрагменты документации из фрагментов кода или наоборот, или и то, и другое из общего представления более высокого уровня?

• Если файлы заголовков и объявления интерфейсов дублируют сведения в реализации кода, то существует ли способ создания файлов заголовков и объявлений интерфейсов из данного кода?

Для структур данных существует аналог SPOT-правила: 'нет лишнего — нет путаницы'. 'Нет лишнего' означает, что структура данных (модель) должна быть минимальной, например, не следует делать ее настолько общей, чтобы она могла представлять ситуации, возникновение которых невозможно. 'Нет путаницы' означает, что положения, которые должны быть обособлены в реальной проблеме, также должны быть обособлены в модели. Коротко говоря, SPOT-правило поддерживает поиск структуры данных, состояния которой имеют однозначное соответствие с состояниями реальной системы, которая будет моделироваться.

Авторы могут добавить некоторые собственные следствия SPOT-правила в контексте Unix- традиций.

• Если данные дублируются из-за кэширования промежуточных результатов некоторых вычислений или поиска, то следует внимательно проанализировать, не является ли это преждевременной оптимизацией. Устаревшие данные кэша (и уровни кода, необходимые для поддержки синхронизации кэша) являются 'неиссякаемым' источником ошибок[43] и даже способны снизить общую производительность, если (как часто случается) издержки управления кэшем превышают ожидания разработчика.

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

Теперь модель должна быть очевидной.

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

4.2.4. Компактность и единый жесткий центр

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

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

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

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

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