1.6. Основы философии Unix
"Unix-философия" возникла вместе с ранними размышлениями Кена Томпсона о том, как сконструировать небольшую, но совершенную операционную систему с ясным служебным интерфейсом. Она развивалась по мере того, как Unix-культура изучала возможности получения максимального эффекта от проекта Томпсона, и в процессе этого развития впитывала уроки "предыдущей истории".
Философия Unix не является формальным методом проектирования. Она не была та свыше" как способ создания теоретически идеального программного обеспечения. Unix-философия (как удачные народные традиции в других инженерных дисциплинах) прагматична и основывается на опыте. Ее следует искать не в официальных методах и стандартах, а скорее в скрытых почти рефлекторных знаниях и опыте, который передается культурой Unix. Она культивирует чувство меры и достаточный скептицизм.
Дуг Макилрой, изобретатель каналов (pipes) в Unix и один из основателей Unix-традиции, сформулировал постулаты философии Unix следующим образом [52].
(i) Заставьте каждую программу хорошо выполнять одну функцию. Для решения новой задачи следует создавать новую программу, а не усложнять старые программы добавлением новых функций.
(ii) Будьте готовы к тому, что вывод каждой программы станет вводом другой, еще неизвестной программы. Не загромождайте вывод посторонней информацией. Избегайте строгих табличных или двоичных форматов ввода. Не настаивайте на интерактивном вводе.
(iii) Проектируйте и создавайте программное обеспечение, даже операционные системы, которые можно будет проверить в самом начале, в идеальном случае в течение нескольких недель. Без колебаний выбрасывайте громоздкие части и перестраивайте их.
(iv) Вместо неквалифицированной помощи используйте инструменты, облегчающие программирование, даже если инструменты приходится создавать "окольными" путями, зная, что некоторые из них будут удалены по окончании использования.
Позднее он обобщил эти положения (процитировано в книге "A Quarter Century of Unix" [74]).
Вот в чем заключается философия Unix: пишите программы, которые выполняют одну функцию и делают это хорошо; пишите программы, которые будут работать вместе; пишите программы, поддерживающие текстовые потоки, поскольку они являются универсальным интерфейсом.
Роб Пайк, который стал одним из великих мастеров языка С, в книге "Notes on С Programming" [62] предлагает несколько иной угол зрения.
Правило 1. Невозможно сказать, где возникнет задержка в программе. "Бутылочные горлышки" возникают в неожиданных местах, поэтому не следует пытаться делать предсказания и исправлять скорость до тех пор, пока не будет точно выяснено, где находится "бутылочное горлышко".
Правило 2. Проводите измерения. Не следует регулировать скорость до тех пор, пока не проведены измерения, и даже после измерений, если одна часть кода подавляет остальные.
Правило 3. Вычурные алгоритмы очень медленные, когда величина n является малой, а она обычно мала. Вычурные алгоритмы имеют большие константы. До тех пор, пока не известно, что n периодически стремится к большим значениям, не следует усложнять алгоритмы. (Даже если n действительно достигает больших значений, сначала используйте правило 2.)
Правило 4. Вычурные алгоритмы более склонны к появлению ошибок, чем простые, и их гораздо сложнее реализовать. Используйте простые алгоритмы, а также простые структуры данных.
Правило 5. Данные доминируют. Если выбраны правильные структуры данных и все организовано хорошо, то алгоритмы почти всегда будут очевидными. Для программирования центральными являются структуры данных, а не алгоритмы[8].
Правило 6. Правила 6 нет.
Кен Томпсон, спроектировавший и реализовавший первую Unix, усилил четвертое правило Пайка афористичным принципом, достойным Дзэн-патриарха:
В случае сомнений используйте грубую силу.
Гораздо сильнее Unix-философия была выражена не высказываниями старейшин, а их действиями, которые воплощает сама Unix. В целом, можно выделить ряд идей.
1. Правило модульности: следует писать простые части, связанные ясными интерфейсами.
2. Правило ясности: ясность лучше, чем мастерство.
3. Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами.
8
Здесь представлено оригинальное дополнение Пайка (см. книгу Брукса, стр. 102). Ссылка указывает на раннее издание книги