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

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

Величайшая наша проблема как культуры — сможем ли мы перерасти предположения, которые так хорошо нам служили, сможем ли мы признать не только интеллектуально, но и силой повседневной практики, что Macintosh-разработчиков можно понять? Их точка зрения в более широком смысле, но менее характерно для Mac описана в "The Inmates Are Running the Asylum" [14], проницательной и логичной книге о том, что ее автор называет дизайном взаимодействия, содержащей (несмотря на случайные причуды) много тяжелой правды, которую следовало бы знать каждому Unix-программисту.

Мы можем уклониться от этого; мы можем остаться служителями культа, привлекая избранное меньшинство лучших и талантливейших, образованную элиту, сфокусированную на нашей исторической роли хранителей программной инфраструктуры и сетей. Но в таком случае наша культура, весьма вероятно, придет в упадок и со временем потеряет динамизм, который поддерживал нас в течение десятилетий. Кто-то другой будет служить людям; кто-то другой придет туда, где будут мощности и деньги, и будет править будущим 92% всего программного обеспечения. Есть вероятность, независимо от того, будет ли этим кто-то именно Microsoft, что они будут делать это с помощью практик и программ, которые нам не очень нравятся.

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

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

Примечательно, что культура Macintosh начала объединяться с нашей — в основе MacOS X стоит Unix, и сегодня Mac-разработчики (хотя и в некоторых случаях не без трудностей) приспосабливают свой разум к изучению достоинств Unix, сфокусированных на инфраструктуре. Аналогично, нашей проблемой будет принять достоинства Macintosh, связанные с ориентацией системы на пользователя.

Имеются также другие признаки того, что Unix-культура избавляется от своей изолированности. Одним из них является слияние, которое, по всей видимости, будет продолжаться, сообщества Unix/открытый исходный код с движением, которое называется "гибкое программирование" (agile programming) [159] . В главе 4 отмечалось, что Unix-программисты удачно ухватились за идею рефакторинга, одного из предубеждений мыслителей гибкого программирования. Рефакторинг и другие концепции гибкого программирования, такие как блочное тестирование (unit-testing) и дизайн вокруг областей (design around stories), кажется, ясно выражают и обостряют практические приемы, которые до этого были широко распространены в Unix-традиции, но только неявно. С другой стороны, Unix-традиция может привнести в гибкое программирование устойчивость и уроки многолетнего опыта. Поскольку открытое программное обеспечение приобретает свою долю рынка, очень вероятно, что эти культуры объединятся, как это было с ранними культурами Internet и Unix после 1980 года.

159

Введение в гибкое программирование представлено на странице Agile Manifesto <http://agilemanifesto.org/>.

20.6. Причины верить

В будущем операционной системы Unix много проблем. Хотели бы мы действительно изменить его?

За более чем тридцатилетнюю историю мы преуспели в разрешении многих трудностей. Мы были первопроходцами лучших практических приемов программной инженерии. Мы создали сегодняшние Internet и Web. Мы создали крупнейшие, наиболее сложные и самые надежные программные системы из когда-либо существовавших. Мы пережили монополию IBM и выступили против монополии Microsoft.

Однако не все это можно назвать триумфом. В 1980-х годах мы почти разрушили свою культуру, согласившись с частным захватом Unix. Мы долго пренебрегали компьютерами низкого класса и нетехническими конечными пользователями и таким образом предоставили Microsoft удобный случай для внедрения низкокачественных стандартов программного обеспечения. Умные наблюдатели неоднократно объявляли крах нашей технологии, сообщества и наших ценностей.

Но мы всегда стремительно возвращались. Мы делаем ошибки, но мы учимся на своих ошибках. Мы передали нашу культуру через поколения; мы впитали многое из лучшего опыта ранних академических хакеров, ARPANET-экспериментаторов, энтузиастов мини-компьютеров и множества других культур. Движение открытого исходного кода возродило силу и идеализм наших ранних лет, и сегодня мы сильнее и многочисленнее, чем когда-либо.

До сих пор доводы против Unix-хакеров всегда были в краткосрочном выигрыше, но проигрывали в долгосрочной перспективе. Мы можем победить, если решимся на это.

Приложения

А Глоссарий аббревиатур

В данном приложении даны определения наиболее важных аббревиатур, используемых в основном тексте книги.

API

Application Programming Interface. Программный интерфейс приложений. Набор процедурных вызовов, который обменивается данными со связываемой библиотекой процедур или ядром операционной системы, или их комбинацией.

BSD

Berkeley System Distribution, или Berkeley Software Distribution. Дистрибутив системы Беркли, или дистрибутив программного обеспечения Беркли. Документальные свидетельства неоднозначны. Общее название дистрибутивов Unix, выпущенных Computer Science Research Group в Калифорнийском университете в Беркли в период между 1976 и 1994 годами, а также Unix-систем с открытым исходным кодом, генетически происходящих от данных дистрибутивов.

CLI

Command Line Interface. Интерфейс командной строки. Считается некоторыми архаичным, но остается весьма полезным в мире Unix.

CPAN

Comprehensive Perl Archive Network. Полный сетевой архив Perl-программ. Центральный Web-репозиторий Perl-модулей и расширений <http://cpan.org>.

GNU

GNU's Not Unix! GNU — не Unix! Рекурсивная аббревиатура для проекта фонда свободного программного обеспечения (Free Software Foundation) по созданию клона Unix с полностью свободным программным обеспечением. Данный проект не достиг абсолютного успеха, однако в его рамках создано множество основных инструментов современной Unix-разработки, включая редактор Emacs и коллекцию компиляторов GNU (GNU Compiler Collection).

GUI

Graphical User Interface. Графический пользовательский интерфейс. Современный стиль интерфейса приложений, использующих мышь, окна и пиктограммы, созданный в лаборатории Xerox PARC в 1970-х годах как противоположность более старым CLI- или rogue-подобным стилям.

IDE

Integrated Development Environment. Интегрированная среда разработки. Автоматизированные инструментальные средства разработки с GUI-интерфейсом для создания кода, описания средств и быстрого просмотра структур данных. В Unix данные средства не получили широкого распространения по причинам, описанным в главе 15.