Философия Unix (Snlkvksnx Unix)

Перейти к навигации Перейти к поиску

Философия Unix — набор культурных норм и философских подходов к разработке программного обеспечения, основанных на опыте ведущих разработчиков операционной системы Unix. Существуют разные формулировки принципов, объясняющих нормы и традиции.

Три принципа Макилроя

[править | править код]

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

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

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

Принципы Ганкарца

[править | править код]

В 1994 году Майк Ганкарц (англ. Mike Gancarz) объединил свой опыт работы над X Window System) с высказываниями из прений, в которых он участвовал со своими приятелями-программистами и людьми из других областей деятельности, так или иначе зависящих от Unix, и вывел в книге «Философия Unix» 9 основных принципов:

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

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

  • позвольте пользователю настраивать окружение;
  • делайте ядра операционной системы маленькими и легковесными;
  • используйте нижний регистр и придерживайтесь кратких названий;
  • не храните тексты программ в виде распечаток («спасите деревья!»);
  • не сообщайте пользователю об очевидном («молчание — золото»);
  • разбивайте сложные задачи на несколько простых, выполняемых параллельно («мыслите „параллельно“»);
  • объединённые части целого есть нечто большее, чем просто их сумма;
  • ищите 90-процентное решение;
  • если можно не добавлять новую функциональность, не добавляйте её («чем хуже, тем лучше»);
  • мыслите иерархически.

Тезисы Рэймонда

[править | править код]

Эрик Рэймонд (англ. Eric S. Raymond) в книге «Искусство программирования в Unix» подытожил философию Unix как широко используемую инженерную философию «Делай это проще, глупец» (принцип KISS). Затем он описал, как эта обобщённая философия применима в качестве культурных норм Unix. И это несмотря на то, что несложно найти несколько нарушений в следующей текущей философии Unix:

  • правило модульности: пишите простые части, соединяемые понятными интерфейсами;
  • правило ясности: ясность лучше заумности;
  • правило композиции: разрабатывайте программы так, чтобы их можно было соединить с другими программами;
  • правило разделения: отделяйте правила (policy) от механизма (mechanism); отделяйте интерфейс от движка (engine);
  • правило простоты: нацельтесь на простоту; добавляйте сложность, только где необходимо;
  • правило экономности: пишите большую программу только когда другими средствами выполнить необходимую задачу не удастся;
  • правило прозрачности: разрабатывайте прозрачные программы для облегчения последующего пересмотра и отладки;
  • правило надёжности: надёжность — дитя прозрачности и простоты;
  • правило представления: храните знания в данных так, чтобы логика программы была тупой и надёжной;
  • правило наименьшего удивления: при разработке интерфейса всегда делайте так, чтобы привычные элементы интерфейса выполняли привычные функции;
  • правило тишины: если программе нечего сказать, пусть лучше молчит;
  • правило восстановления: если программа должна аварийно завершиться, делайте это шумно и как можно быстрее;
  • правило экономии: время программиста дорого; сократите его, используя машинное время;
  • правило генерации: избегайте ручного набора кода; при любом удобном случае пишите программы, которые бы писали программы;
  • правило оптимизации: сначала — опытный образец, потом — «причесывание»; добейтесь стабильной работы, только потом оптимизируйте;
  • правило многообразия: отвергайте все утверждения о «единственно правильном пути»;
  • правило расширяемости: разрабатывайте для будущего — оно наступит быстрее, чем вы думаете;

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

Цитаты

[править | править код]

Некоторые широко известные высказывания, характеризующие культуру разработки Unix:

  • «Unix прост. Но надо быть гением, чтобы понять его простоту» — Деннис Ритчи;
  • «Unix не предназначен для ограждения своих пользователей от глупостей, поскольку это оградило бы их и от умных вещей» — Дуг Гвин;
  • «Unix никогда не говорит „пожалуйста“» — Роб Пайк;

Критика

[править | править код]

Философия UNIX критиковалась в книге «The UNIX-HATERS Handbook», изданной в начале 1990-х годов.

По мнению редакторов книги, подход Unix приводит к появлению решений, сделанных наспех, без должного продумывания архитектуры, после чего данные решения канонизируются (enshrined), то есть объявляются вечной классикой. Например, таким решением, по их мнению, являются lock files — временные файлы без содержимого, создаваемые как пометка того факта, что какая-то программа находится в процессе исполнения.

X Window System была подвергнута критике за отделение в ней механизма (engine) от политики (policy), что привело к отсутствию в UNIX стандарта на политики управления пользовательским интерфейсом и большим затруднениям при разработке приложений, использующих GUI.

NFS была подвергнута критике за изначально порочный подход к архитектуре — попытку создать stateless файл-сервер при том, что это принципиально невозможно. Когда же невозможность поддержки некоторых важных вещей стала очевидной, к NFS прикрутили «костыль» под названием процесса lockd.

Но, в то же время, критикуемые в этой книге подходы, начатые в *NIX, плавно обосновываются и в операционных системах семейств Windows и унаследованы macOS.

Ссылки

[править | править код]
Источник — https://ru.wikipedia.org/w/index.php?title=Философия_Unix&oldid=130596705