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

В основе большинства неприятностей Дж. Рэндома Ньюби (и крупномасштабных проблем качества, которые они подразумевают) лежит прозрачность — или, вернее, ее недостаток. Невозможно устранить проблему в коде, который невозможно посмотреть изнутри. Фактически в любой программе с нетривиальным API-интерфейсом невозможно даже должным образом использовать то, что нельзя увидеть изнутри. Документация неадекватна не только на практике, но и в принципе. Она не способна передать все нюансы, реализованные в коде.

В главе 6 отмечалось, как важна для хорошей программы центральная прозрачность. Компоненты, состоящие только из объектного кода, разрушают прозрачность программной системы. С другой стороны, неудачи повторного использования кода гораздо менее вероятно нанесут ущерб, когда повторно используемый код доступен для чтения и модификации. Хорошо комментированный исходный код сам по себе является документацией. Ошибки в исходном коде можно устранить. В исходный код можно включить средства измерения и скомпилировать для отладки, что позволяет упростить проверку его поведения в непонятных случаях, а кроме того, всегда можно изменить поведение программы в случае необходимости.

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

Важность прозрачности и проблема устаревания кода являются теми причинами, по которым следует требовать открытости повторно используемого кода для проверки и модификации [135] . Это лишь предварительный аргумент в пользу того, что сейчас называется "открытым исходным кодом". Понятие "открытый исходный код" имеет более важный смысл, чем просто требование прозрачности и видимости кода.

16.3. От повторного использования к открытому исходному коду

135

Агентство NASA, в котором целенаправленно создавалось программное обеспечение, предназначенное для использования в течение десятилетий, научилось настаивать на доступности исходного кода для всех создателей программного обеспечения для аэрокосмической техники.

Компоненты ранней Unix, ее библиотеки и связанные утилиты распространялись в виде исходного кода. Эта открытость была жизненно важной частью культуры Unix. В главе 2 уже говорилось о том, как после разрушения этой традиции в 1984 году Unix утратила свою первоначальную движущую силу, и как десять лет спустя возникновение GNU-инструментария и Linux побудило сообщество "вернуться к ценностям" открытого исходного кода.

В настоящее время открытый исходный код снова является одним из наиболее мощных инструментов в коллекции любого Unix-программиста.

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

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

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

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

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

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

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

16.4. Оценка проектов с открытым исходным кодом

В Internet доступны для использования буквально терабайты исходных кодов для системных и прикладных Unix-программ, служебных библиотек, GUI-инструментариев и аппаратных драйверов. Большинство из них с помощью стандартных инструментов можно скомпилировать и запустить за считанные минуты: ./configure; make; make install; для выполнения инсталляционной части обычно требуются привилегии администратора.

Люди за пределами мира Unix (особенно нетехнические пользователи) склонны рассматривать программное обеспечение с открытым исходным кодом (или "свободное") как непременно худшее по сравнению с коммерческим, т.е. как низкокачественное, ненадежное и вызывающее больше проблем, чем способно решить. Они упускают из виду важный момент: в общем, программное обеспечение с открытым исходным кодом пишется людьми, которым оно не безразлично, которые сами его используют, и, опубликовывая его, рискуют своей личной репутацией. Они также склонны тратить меньше времени на совещания, давние изменения конструкции и бюрократические издержки. Следовательно, они сильнее мотивированы и лучше нацелены на выполнение качественной работы, чем оплачиваемые невольники, для которых главное — соблюсти невозможные сроки завершения проекта в частных предприятиях.