Искусство программирования для Unix
Шрифт:
Дуг Макилрой, изобретатель каналов (pipes) в Unix и один из основателей Unix-радиции, сформулировал постулаты философии Unix следующим образом [52].
• Заставьте каждую программу хорошо выполнять одну функцию. Для решения новой задачи следует создавать новую программу, а не усложнять старые программы добавлением новых функций.
• Будьте готовы к тому, что вывод каждой программы станет вводом другой, еще неизвестной программы. Не загромождайте вывод посторонней информацией. Избегайте строгих табличных или двоичных форматов
• Проектируйте и создавайте программное обеспечение, даже операционные системы, которые можно будет проверить в самом начале, в идеальном случае в течение нескольких недель. Без колебаний выбрасывайте громоздкие части и перестраивайте их.
• Вместо неквалифицированной помощи используйте инструменты, облегчающие программирование, даже если инструменты приходится создавать "окольными" путями, зная, что некоторые из них будут удалены по окончании использования.
Позднее он обобщил эти положения (процитировано в книге "A Quarter Century of Unix" [74].
Вот в чем заключается философия Unix: пишите программы, которые выполняют одну функцию и делают это хорошо; пишите программы, которые будут работать вместе; пишите программы, поддерживающие текстовые потоки, поскольку они являются универсальным интерфейсом.
Роб Пайк, который стал одним из великих мастеров языка С, в книге "Notes on С Programming" [62] предлагает несколько иной угол зрения.
Правило 1. Невозможно сказать, где возникнет задержка в программе. "Бутылочные горлышки" возникают в неожиданных местах, поэтому не следует пытаться делать предсказания и исправлять скорость до тех пор, пока не будет точно выяснено, где находится "бутылочное горлышко".
Правило 2. Проводите измерения. Не следует регулировать скорость до тех пор, пока не проведены измерения, и даже после измерений, если одна часть кода подавляет остальные.
Правило 3. Вычурные алгоритмы очень медленные, когда величина п является малой, а она обычно мала. Вычурные алгоритмы имеют большие константы. До тех пор, пока не известно, что п периодически стремится к большим значениям, не следует усложнять алгоритмы. (Даже если п действительно достигает больших значений, сначала используйте правило 2.)
Правило 4. Вычурные алгоритмы более склонны к появлению ошибок, чем простые, и их гораздо сложнее реализовать. Используйте простые алгоритмы, а также простые структуры данных.
Правило 5. Данные доминируют. Если выбраны правильные структуры данных и все организовано хорошо, то алгоритмы почти всегда будут очевидными. Для программирования центральными являются структуры данных, а не алгоритмы6.
Правило 6. Правила 6 нет.
Кен Томпсон, спроектировавший и реализовавший первую Unix,
В случае сомнений используйте грубую силу.
Гораздо сильнее Unix-философия была выражена не высказываниями старейшин, а их действиями, которые воплощает сама Unix. В целом, можно выделить ряд идей.
1. Правило модульности: следует писать простые части, связанные ясными интерфейсами.
2. Правило ясности: ясность лучше, чем мастерство.
3. Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами.
4. Правило разделения: следует отделять политику от механизма и интерфейсы от основных модулей.
5. Правило простоты: необходимо проектировать простые программы и "добавлять сложность" только там, где это необходимо.
6. Правило расчетливости: пишите большие программы, только если после демонстрации становится ясно, что ничего другого не остается.
7. Правило прозрачности: для того чтобы упростить проверку и отладку программы, ее конструкция должна быть обозримой.
8. Правило устойчивости: устойчивость— следствие прозрачности и простоты.
9. Правило представления: знания следует оставлять в данных, чтобы логика программы могла быть примитивной и устойчивой.
10. Правило наименьшей неожиданности: при проектировании интерфейсов всегда следует использовать наименее неожиданные элементы.
11. Правило тишины: если программа не может "сказать" что-либо неожиданное, то ей вообще не следует "говорить".
12. Правило исправности: когда программа завершается аварийно, это должно происходить явно и по возможности быстро.
13. Правило экономии: время программиста стоит дорого; поэтому экономия его времени более приоритетна по сравнению с экономией машинного времени.
14. Правило генерации: избегайте кодирования вручную; если есть возможность, пишите программы для создания программ.
15. Правило оптимизации: создайте опытные образцы, заставьте их работать, прежде чем перейти к оптимизации.
16. Правило разнообразия: не следует доверять утверждениям о "единственно верном пути".
17. Правило расширяемости: проектируйте с учетом изменений в будущем, поскольку будущее придет скорее, чем кажется.
Новичкам в Unix стоит поразмышлять над данными принципами. Технические тексты по разработке программного обеспечения рекомендуют большую их часть, однако в других операционных системах, как правило, имеется недостаток необходимых средств и традиций для их внедрения, поэтому большинство программистов не могут применять их последовательно. Они принимают несовершенные инструменты, плохие конструкции, перенапряжение и распухший код как должное, а впоследствии удивляются, почему все это раздражает поклонников Unix.