Простые правила чтения специальной литературы
Хороших и полезных книг в принципе не может быть много. Иначе вы посвятите все рабочее время чтению. Тут уместно вспомнить второе правило Аникеева
[12]; кстати, все три его правила стоит привести целиком. Итак, настоящий исследователь должен:
• быть достаточно ленивым. Чтобы не делать лишнего, не ковыряться в мелочах;
• поменьше читать. Те, кто много читает, отвыкают самостоятельно мыслить;
• быть непоследовательным, чтобы, не упуская цели, интересоваться и замечать побочные эффекты.
Может показаться странным, что в теме о технической книге я сослался на художественное произведение. Будучи студентом, я однажды услышал от заведующего нашей кафедры вычислительных и радиоэлектронных систем профессора и академика Михаила Борисовича Игнатьева совет, касавшийся обычной лабораторной работы, связанной с телеконференциями. Дословно он звучал так: «Я бы посоветовал Вам почитать Станиславского. Телеконференции – это большое представление, шоу…». Если рекомендацию тогда я всерьёз не воспринял, то сегодня оцениваю её как весьма полезную.
Когда натыкаешься в Сети на очередное несдержанное восклицание «must have», подобная постановка вопроса коробит сама по себе. Представьте, что кто-то открыл для себя и полюбил варёный лук. И теперь если ты его не «must have», то как бы и не в струе, и вообще от жизни отстал. Смешно, конечно, но шутки шутками…
Технические книжки – это не бессмертные произведения графа Толстого. К ним должен быть суровый, сугубо индивидуальный и безжалостный подход без какой-либо оглядки на чужое мнение. Прежде чем начать читать, возьмите листок бумаги, оптимально формата А4 – сложенный пополам, он удачно вкладывается в книгу, служа одновременно и закладкой. И запаситесь карандашом. Пользователям устройств для чтения электронных книг, к коим я тоже отношусь, необходимо освоить функции вставки в текст своих заметок.
Если «читалка» этого не позволяет, придётся всё-таки обратиться к бумаге или сменить устройство на более функциональное.
Теперь, по мере чтения, начинайте делать пометки в стиле «с. 11, это мнение плохо обосновано, потому что…», «стр. 25, хорошая мысль, применимо также в ситуации…». Очевидно, для пометок типа «у автора N выводы другие, но если обобщить…» потребуется немного больше времени.
Если, пролистав с полсотни страниц, вы не сделаете ни одной пометки, то можете смело закрывать сие произведение. В топку бросать, наверное, не надо, но поберегите своё время. Если же к концу прочтения вам хватит листа А4, исписанного убористым почерком, для всех пометок, то можете считать, что чтение прошло не зря. Ну а если одного листа не хватило… Тогда смело идите на свой любимый интернет-форум и там поделитесь с коллегами своими находками. Когда вместо малоинформативного «must have», используя все тот же испещрённый пометками лист, вы сможете передать пользу от прочитанного, коллеги будут вам чрезвычайно признательны за рекомендации и собственное сэкономленное время.
Литература и программное обеспечение
Как вы знаете, в софтостроении, часто употребляется термин «(на)писать программу». Первые программы для ЭВМ не писали, а составляли. Составляли из машинных команд. Кодировали. Пробивали дырочки на картонных перфокартах. Затем появились языки высокого уровня, приближенные к естественным. Тогда программы стали именно писать. Сейчас, когда отрасль предпринимает попытки индустриализации, можно услышать, что программы вновь кодируют. И снова это связано с разделением труда: кодируют по спецификациям проектировщиков или по наитию пользовательских историй.
В литературе выражение «закодировать» пока не привилось, но налёт индустриальности уже коснулся и этой области человеческой деятельности. Миллионы журналистов ежедневно вставляют свои модули в разные форматы периодических изданий: от экспертных авторских колонок до банальной «джинсы»[131]. Здравицы и некрологи пишут загодя. Стереотипная массовая литература вроде карманных детективов и любовных романов поставлена на поток.
Разделение труда на «автора» и «кодировщика» в подобном процессе также присутствует. Даже если автор номинальный, издающий под своим брендом труд неизвестных литераторов, что, к сожалению, случается.
В итоге обнаруживаем немало сходства в процессе. Взглянем на классификацию создаваемых продуктов, плодов труда, приведённую в таблице.
Сходство усиливается. Обратите внимание на технологию использования продуктов. Исполнительной средой для программы является ЭВМ. Для литературного произведения в таковой роли выступает наш мозг. Глубокое погружение человека в процесс чтения соответствует 100 % загрузке процессора, а то и даже «зависанию». Откладывание книжки после пары просмотренных страниц говорит о несовместимости программы с текущей конфигурацией исполнительной среды.
Настало время посмотреть на архитектуру продуктов. Прежде всего, на степень ее абстрактности.
Существуют программные системы, представляющие собой весьма общее решение, по сути, каркас, фреймворк, который другой программист может использовать для решения своих задач. В литературе подобные фреймворки тоже встречаются. Как правило, на них ссылаются: «Это сюжет, основу которого составляет…». Наиболее известным разработчиком фреймворков является Вильям Шекспир. Базовая подсистема уровня ядра «Быть или не быть», обёрнутая собственным кодом писателя, присутствует практически в любом произведении, претендующем на глубину. Если придерживаться аналогий, Линус Торвальдс – Шекспир современного мира операционных систем на базе Linux.
В противоположность каркасам, встречаются самодостаточные программы, у которых, как говорится, не убавить и не прибавить. Законченные продукты решают поставленные пользователем задачи. Их надо заключать в рамочку хрестоматийных произведений, используя в соответствии с собственной программой обучения, например школьной.
Вспомним и о таком важном свойстве, как открытость архитектуры. Программы с открытой архитектурой позволяют создавать свои встраиваемые модули расширений[132] и легко интегрируются с другими программами. Не нарушая общей логики, совсем нетрудно взять пару ключевых героев и дописать эпизод из их жизни, не вошедший в книгу.
Монолитные же программы закрыты. Стоит потянуть за одну ниточку, как сдвинутся целые пласты. Только автору под силу внести дополнения в свое произведение. Дописать самостоятельный «приквел» или «сиквел» к «Войне и миру» – задача практически невыполнимая.
Наконец, существует как пакетная работа с программами, так и диалоговая. Пакетная обработка позволяет результат одной программы использовать для другой. Неважно, что главного героя увозят на тарелке инопланетяне. Заводим нового, помещаем его в старые декорации – вот и готово продолжение.
В диалоговом режиме все ненужные подробности скрывает красивый интерфейс, как правило, графический. Это не только комиксы и детские книги с обилием иллюстраций. Вполне можно обойтись текстовым режимом, лаконично излагая суть и делая сноски и ссылки для любознательных.
Хотя софтостроение довольно часто сравнивают со строительством домов, видимо, желая поскорее свести роль программистов к укладке готовых кирпичей и тем самым закрыть надоевшую проблему огромного числа просроченных или неудачных проектов, не бойтесь аналогий с писательским трудом. Ведь разработка программ совсем не означает необходимость всякий раз создавать «нетленку». В конце концов, хороший plug-in во много раз полезнее плохого фреймворка.
Вместо послесловия, или Краткое изложение «Оснований»
В удивительные и непредсказуемые времена мы в испуге цепляемся за прошлое.
А. Азимов. «Край основания»
Вначале, как известно, было Слово™. И Слово™ содержало ровно столько байтов, сколько допускала архитектура ЭВМ. Поэтому 1 К не был равным 1 кбайт.
Из Слов™ стали составлять настолько скучные и однообразные на вид инструкции, что выполнять их могла только ЭВМ. Или самые упорные из составителей – в своем уме. И назвали эту технологию Программированием© в Машинных Кодах™. Вскоре парни, вооружённые Программированием в Машинных Кодах™ сделали Первую© Систему®. Далее значки торговых марок и копирайта я опускаю.
Когда парни сделали Первую Систему, их стали нагружать внесением в неё новых функций. Парни настолько были заняты этим делом, что у них едва хватало времени на чашку кофе и сигарету. Кроме того, они несколько состарились за работой и стали Старыми Чудаками.
И тут появились Молодые Парни, которым пришла в голову Мысль: можно вместо Машинных Кодов использовать их Мнемонику. Понятную человеку. Но, к сожалению, непонятную ЭВМ. Пришлось им в Машинных Кодах составлять вспомогательную программу – Транслятор, которая переводила Мнемокод в Машинный Код. На самом деле мысль Молодые Парни подслушали у Старых Чудаков, но тем, как мы помним, было не до реализации этой Мысли. И Молодые Парни, вооружённые Программированием в Мнемокодах, сделали Вторую Систему.
