Философия UNIX

Дуг Макилрой , изобретатель каналов UNIX и один из основателей традиции UNIX, обобщил философию следующим образом:

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

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

Философия UNIX сводится к 9 основным принципам:

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

Менее важные 10 принципов (не снискали всеобщего признания в качестве частей философии UNIX и в некоторых случаях являлись предметом горячих споров):

  • Позвольте пользователю настраивать окружение.
  • Делайте ядра операционной системы маленькими и легковесными.
  • Используйте нижний регистр и придерживайтесь кратких названий.
  • Не храните тексты программ в виде распечаток ("Спасите деревья!").
  • Не сообщайте пользователю об очевидном ("Молчание — золото").
  • Разбивайте сложные задачи на несколько простых, выполняемых параллельно ("Мыслите "параллельно"").
  • Объединённые части целого есть нечто большее, чем просто их сумма.
  • Ищите 90-процентное решение.
  • Если можно не добавлять новую функциональность, не добавляйте её ("Чем хуже, тем лучше").
  • Мыслите иерархически.

Общие правила UNIX

  • Правило модульности: Пишите простые части, соединяемые понятными интерфейсами.
  • Правило ясности: Ясность лучше заумности.
  • Правило композиции: Разрабатывайте программы так, чтобы их можно было соединить с другими программами.
  • Правило разделения: Отделяйте правила (policy) от механизма (mechanism); отделяйте интерфейс от движка (engine).
  • Правило простоты: Нацельтесь на простоту; добавляйте сложность, только где необходимо.
  • Правило экономности: Пишите большую программу только когда другими средствами выполнить необходимую задачу не удастся.
  • Правило прозрачности: Разрабатывайте прозрачные программы для облегчения последующего пересмотра и отладки.
  • Правило надёжности: Надёжность — дитя прозрачности и простоты.
  • Правило представления: Храните знания в данных так, чтобы логика программы была тупой и надёжной.
  • Правило наименьшего удивления : При разработке интерфейса всегда делайте как можно меньше неожиданных вещей.
  • Правило тишины: Если программе нечего сказать, пусть лучше молчит.
  • Правило восстановления: Если надо выйти из строя, делайте это шумно и как можно быстрее.
  • Правило экономии: Время программиста дорого; сократите его, используя машинное время.
  • Правило генерации: Избегайте ручного набора кода; при любом удобном случае пишите программы, которые бы писали программы.
  • Правило оптимизации: Сначала — опытный образец, потом — «причесывание». Добейтесь стабильной работы, только потом оптимизируйте.
  • Правило многообразия: Отвергайте все утверждения об «единственно правильном пути».
  • Правило расширяемости: Разрабатывайте для будущего. Оно наступит быстрее, чем вы думаете.

Источники: