Книга: Дефрагментация мозга. Софтостроение изнутри

Литература и программное обеспечение

Литература и программное обеспечение

Как вы знаете, в софтостроении, часто употребляется термин «(на)писать программу». Первые программы для ЭВМ не писали, а составляли. Составляли из машинных команд. Кодировали. Пробивали дырочки на картонных перфокартах. Затем появились языки высокого уровня, приближенные к естественным. Тогда программы стали именно писать. Сейчас, когда отрасль предпринимает попытки индустриализации, можно услышать, что программы вновь кодируют. И снова это связано с разделением труда: кодируют по спецификациям проектировщиков или по наитию пользовательских историй.

В литературе выражение «закодировать» пока не привилось, но налёт индустриальности уже коснулся и этой области человеческой деятельности. Миллионы журналистов ежедневно вставляют свои модули в разные форматы периодических изданий: от экспертных авторских колонок до банальной «джинсы»[131]. Здравицы и некрологи пишут загодя. Стереотипная массовая литература вроде карманных детективов и любовных романов поставлена на поток.

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

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

Сходство усиливается. Обратите внимание на технологию использования продуктов. Исполнительной средой для программы является ЭВМ. Для литературного произведения в таковой роли выступает наш мозг. Глубокое погружение человека в процесс чтения соответствует 100 % загрузке процессора, а то и даже «зависанию». Откладывание книжки после пары просмотренных страниц говорит о несовместимости программы с текущей конфигурацией исполнительной среды.

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

Существуют программные системы, представляющие собой весьма общее решение, по сути, каркас, фреймворк, который другой программист может использовать для решения своих задач. В литературе подобные фреймворки тоже встречаются. Как правило, на них ссылаются: «Это сюжет, основу которого составляет…». Наиболее известным разработчиком фреймворков является Вильям Шекспир. Базовая подсистема уровня ядра «Быть или не быть», обёрнутая собственным кодом писателя, присутствует практически в любом произведении, претендующем на глубину. Если придерживаться аналогий, Линус Торвальдс – Шекспир современного мира операционных систем на базе Linux.

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

Вспомним и о таком важном свойстве, как открытость архитектуры. Программы с открытой архитектурой позволяют создавать свои встраиваемые модули расширений[132] и легко интегрируются с другими программами. Не нарушая общей логики, совсем нетрудно взять пару ключевых героев и дописать эпизод из их жизни, не вошедший в книгу.

Монолитные же программы закрыты. Стоит потянуть за одну ниточку, как сдвинутся целые пласты. Только автору под силу внести дополнения в свое произведение. Дописать самостоятельный «приквел» или «сиквел» к «Войне и миру» – задача практически невыполнимая.

Наконец, существует как пакетная работа с программами, так и диалоговая. Пакетная обработка позволяет результат одной программы использовать для другой. Неважно, что главного героя увозят на тарелке инопланетяне. Заводим нового, помещаем его в старые декорации – вот и готово продолжение.

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

Хотя софтостроение довольно часто сравнивают со строительством домов, видимо, желая поскорее свести роль программистов к укладке готовых кирпичей и тем самым закрыть надоевшую проблему огромного числа просроченных или неудачных проектов, не бойтесь аналогий с писательским трудом. Ведь разработка программ совсем не означает необходимость всякий раз создавать «нетленку». В конце концов, хороший plug-in во много раз полезнее плохого фреймворка.

Оглавление книги