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

Данные факторы оказались, однако, не настолько уравновешенными, как это может показаться из приведенного выше описания. Модернизация таких функций серверных операционных систем, как множество классов привилегий и полная многозадачность, в клиентской операционной системе представляется очень трудной задачей, и, весьма вероятно, нарушит совместимость с предыдущими версиями клиента, а также приведет к многочисленным проблемам безопасности. С другой стороны, проблем связанных с внедрением GUI-интерфейса в серверную операционную систему, вполне можно избежать при условии наличия высококвалифицированного персонала и недорогих аппаратных ресурсов. Как и в строительстве, восстановить надстройку на поверхности прочного фундамента проще, чем заменить фундамент без разрушения надстройки.

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

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

Часть II Проектирование

4 Модульность: четкость и простота

Есть два способа конструирования программного обеспечения. Один из них заключается в том, чтобы создавать такие простые программы, в которых нет недостатков; другой — в том, чтобы создавать программы настолько сложные, чтобы в них не было очевидных недостатков. Первый метод значительно труднее.

The Emperor's Old Clothes, CACM, февраль 1981

-Ч. А. Р. Хоар (С. A. R. Hoare)

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

Ранние разработчики Unix были в числе первопроходцев модульности программного обеспечения. До их прихода правило модульности было теорией компьютерной науки, но не инженерной практикой. В книге "Design Rules" [2], радикальном учении об экономических основах модульности в инженерном дизайне, авторы используют развитие компьютерной индустрии в качестве учебного примера и доказывают, что сообщество Unix фактически было первым в систематическом применении модульной декомпозиции в производстве программного обеспечения в отличие от аппаратного обеспечения. Модульность аппаратного обеспечения, несомненно, была одной из основ инженерии с момента принятия стандартной винтовой резьбы в конце 19-го столетия.

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

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