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

Позднее он обобщил эти положения (процитировано в книге "A Quarter Century of Unix" [74].

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

Роб Пайк, который стал одним из великих мастеров языка С, в книге "Notes on С Programming" [62] предлагает несколько иной угол зрения.

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

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

Правило 3. Вычурные алгоритмы очень медленные, когда величина п является малой, а она обычно мала. Вычурные алгоритмы имеют большие константы. До тех пор, пока не известно, что п периодически стремится к большим значениям, не следует усложнять алгоритмы. (Даже если п действительно достигает больших значений, сначала используйте правило 2.)

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

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

Правило 6. Правила 6 нет.

Кен Томпсон, спроектировавший и реализовавший первую Unix, усилил четвертое правило Пайка афористичным принципом, достойным Дзэн-патриарха:

В случае сомнений используйте грубую силу.

Гораздо сильнее Unix-философия была выражена не высказываниями старейшин, а их действиями, которые воплощает сама Unix. В целом, можно выделить ряд идей.

1. Правило модульности: следует писать простые части, связанные ясными интерфейсами.

2. Правило ясности: ясность лучше, чем мастерство.

3. Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами.

4. Правило разделения: следует отделять политику от механизма и интерфейсы от основных модулей.

5. Правило простоты: необходимо проектировать простые программы и "добавлять сложность" только там, где это необходимо.

6. Правило расчетливости: пишите большие программы, только если после демонстрации становится ясно, что ничего другого не остается.

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

8. Правило устойчивости: устойчивость— следствие прозрачности и простоты.

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

10. Правило наименьшей неожиданности: при проектировании интерфейсов всегда следует использовать наименее неожиданные элементы.

11. Правило тишины: если программа не может "сказать" что-либо неожиданное, то ей вообще не следует "говорить".

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

13. Правило экономии: время программиста стоит дорого; поэтому экономия его времени более приоритетна по сравнению с экономией машинного времени.

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

15. Правило оптимизации: создайте опытные образцы, заставьте их работать, прежде чем перейти к оптимизации.

16. Правило разнообразия: не следует доверять утверждениям о "единственно верном пути".

17. Правило расширяемости: проектируйте с учетом изменений в будущем, поскольку будущее придет скорее, чем кажется.

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

1.6.1. Правило модульности: следует писать простые части, связанные ясными интерфейсами

Как однажды заметил Браян Керниган, "управление сложностью является сущностью компьютерного программирования" [41]. Отладка занимает большую часть времени разработки, и выпуск работающей системы обычно в меньшей степени является результатом талантливого проектирования, и в большей — результатом должного управления, исключающего многократное повторение ошибок.