Помоги проекту - поделись книгой:
Третий день начался ударными темпами. Удалось, буквально ткнув пальцем в небо, выяснить причину ошибки в модуле. Ею оказался настолько искусно криво написанный цикл в одной из многочисленных функций, что не сразу была видна его нехорошая тенденция при определённых условиях превращаться в бесконечный. Зная привычку авторов копировать текст, мы нашли и исправили пару таких же мест и в других функциях. Тем не менее модули все ещё не запускались в штатном режиме, но за пару часов экспериментов мы выяснили, что если некоторые библиотеки подключить статически, а не динамически, то всё в итоге будет жить нормально. Время как раз подходило к вечеру, мы оперативно отослали Блезу, который сидел у заказчика и, заговаривая ему зубы, ждал результатов, исправленный модуль и приступили к записи на диск наработанных за последние дни файлов. Провозились с этим до семи часов вечера, а дело было в пятницу, когда народ старается уйти с работы пораньше. В зал опять зашёл менеджер, осведомился о планах на вечер и, услышав, что всё сделано, обрадовался и даже предложил подвезти нас до города.
Хорошо там, где нас нет
Читатель может справедливо подумать, что пример нашей конторы не показателен. Она маленькая, да и специалистов сейчас повсеместно не хватает, они
дороги, а для небольших фирм зачастую недоступны. Однако с подобными проблемами сталкиваются практически все мои знакомые и коллеги. Если фирма с 50 % национального рынка электронных платежей вполне может работать без системы управления версиями исходного кода и дублированием таблиц в базе данных, то что же тогда говорить о стартапе…
Зато вы можете быть спокойными: без работы в ближайшие десятилетия не останетесь. Некоторые мои друзья в США жаловались на некоторую неопределённость в связи с разыгравшимся там кризисом лопнувших «дот-комов». Но вряд ли следует бояться заразиться насморком во время эпидемии чумы.
О технических книгах
Дефрагментация мозгов
Современное софтостроение заслуженно забыто наукой. Ну а что вы хотите, если на вопрос «Почему нет науки на конференциях и в публикациях?» получаешь однозначный ответ «Никакая наука рынку не нужна» [129] . В результате на первый план выходят повара, написавшие очередную порцию рецептов приготовления пиццы и винегрета из найденных в холодильнике продуктов корпораций.
Ошибочно полагать, что такая ситуация возникла недавно. Отрицательная динамика степени полезности технических книг наблюдалась уже в начале 1990-х годов. Например, С. Дмитренко в предисловии к своему переводу известной книги Leo Brodie «Thinking FORTH. A Language and Philosophy for Solving Problems» в 1993 году писал:
Можно сказать много грустных слов о тенденциозности современной околотехнической литературы, о переориентации отечественных программистов и разработчиков с исследовательских и новаторских на чисто коммерческие работы, о складывающемся монополизме отнюдь не лучших (зато более хватких) производителей компьютеров и программного обеспечения и т. д. И все же, несмотря на эти признаки нарастающего вырождения в нашем, да и мировом компьютерном деле, я надеюсь, что подъем наступит, и мы будем его свидетелями и реализаторами.
Нынешняя «гуглизация» позволяет быстро находить недостающие фрагментарные знания, зачастую забываемые уже на следующий день, если не час. Поэтому ценность книг как систематизированного источника информации, казалось бы, должна только возрастать. Действительно, автору бессмысленно брать на себя функции интеллектуального фильтра RSS [130] , составляя компиляции из содержимого чужих блогов. Кроме стоящих вне конкуренции учебников остаётся в основном только конкретизация – узкоспециализированная проработанная технологическая тема либо обобщение концептуальных наработок и практического опыта.
Но для возрастания значения книг на фоне всеобщей фрагментации знаний необходимо умение аудитории читать и усваивать длинные тексты, неуклонно снижающееся последние десятилетия.
Как-то раз сидели мы с хорошим знакомым на террасе его уютного дома и, потягивая из железных трубочек чай-мате, обсуждали, ни много, ни мало, но смену парадигмы мышления. Долгий опыт университетского преподавателя Павла Андреевича Калугина ныне обогатился добавлением в курс информатики такой эклектики, как Enterprise Java. Проблемы подобные курсы вызывают больше не у студентов, а у обладающего системным образованием и мышлением преподавателя, вынужденного каким-то образом связывать противоречивое и выстраивать логику там, где её изначально не было.
Почему же относительно легко студентам? Дело, прежде всего, в смене образа мыслей, а может быть, и восприятия самой действительности. Мир – это такая очень большая и сложная компьютерная игра, а преподаватели, соответственно, должны обучать не премудростям стратегий познания мира, а практическим приёмам, секретным кодам и даже шулерству, чтобы пройти в этой игре на следующий уровень. Этакие «мастера ключей» из Матрицы. Про то, что в игре продукты на столе появляются прямо из холодильника, тоже стоит упомянуть.
Изредка мне приходится практиковать обучение СУБД, где я столкнулся ровно с тем же явлением. Группа стажеров примерно моего возраста и старше всю неделю честно старалась вникнуть в детали, написанные мелким шрифтом после каждого слайда, уместить знания в некую систему, желательно, не диссонирующую с уже имеющейся в голове.
И напротив, аудитория примерно 20–25 лет оказалась совершенно равнодушна к пояснительному тексту. Если картинка слайда была удачной, то она более-менее откладывалась в памяти. Вдобавок, шло конспектирование некоторых случаев из моей практики с короткими кусками кода. Иное дело – лабораторные работы, когда решение находилось увлекательным методом «научного тыка». Если же метод не срабатывал, то ко мне обращались с просьбой подсказать «код доступа для прохождения на следующий уровень».
Много копий сломано в обывательских дискуссиях о так называемом клиповом мышлении, шаблонности, «плохом образовании» вкупе с апокалиптическими прогнозами и прочим. Хотя на самом деле пока непонятно, к чему приведёт тенденция в перспективе ближайших десятилетий. Во фрагментарном «клиповом» мышлении есть и свои плюсы: способность быстро решать типовые задачи, широкая квалификация и мобильность, меньшие затраты на массовое образование. Минусы тоже ясны. В апокалипсис технократии я не верю, всегда будут рождаться способные дети и существовать ограниченное число учебных заведений, дающих жутко дорогое фундаментальное образование, вроде того, что было общедоступным в СССР. Видимо, этого должно хватить на поддержку критичных технологий цивилизации и дальнейшее их развитие.
Является ли фрагментарное мышление приспосабливанием к многократно увеличившемуся потоку информации? Отчасти да, только это скорее не адаптация, а инстинктивная защита. Чтобы осознанно фильтровать информацию о некоторой системе с минимальными рисками пропустить важные сведения, нужно иметь чётко сформированные представления о ней, её структуре и принципах функционирования. Если, например, у стажера нет знаний о СУБД в целом, то курс по SQL Server – конкретной её реализации, сводится к запоминанию типовых ситуаций и решений из набора сопутствующих практических работ. Вся теоретическая часть при этом просто не проходит фильтры.
В такой ситуации альтернативой ухода от информационных потоков и некачественного образования во фрагментарную реальность является самообразование на базе полезных книг. Потому что хорошая книга – самый эффективный способ дефрагментации ваших мозгов. Если не верите, возможно, вас убедит рассказ классика научной фантастики А. Азимова «Профессия» о неудавшемся программисте.
Как вы заметили, я упомянул о полезности книг, но никакого объективного определения этому критерию не дал, хотя сам же и сетовал на недостаток науки. Не претендуя на приоритет и оригинальность, поделюсь следующими несложными правилами и эвристиками.
Простые правила чтения специальной литературы
Хороших и полезных книг в принципе не может быть много. Иначе вы посвятите все рабочее время чтению. Тут уместно вспомнить второе правило Аникеева
[12]; кстати, все три его правила стоит привести целиком. Итак, настоящий исследователь должен:
• быть достаточно ленивым. Чтобы не делать лишнего, не ковыряться в мелочах;
• поменьше читать. Те, кто много читает, отвыкают самостоятельно мыслить;
• быть непоследовательным, чтобы, не упуская цели, интересоваться и замечать побочные эффекты.
Может показаться странным, что в теме о технической книге я сослался на художественное произведение. Будучи студентом, я однажды услышал от заведующего нашей кафедры вычислительных и радиоэлектронных систем профессора и академика Михаила Борисовича Игнатьева совет, касавшийся обычной лабораторной работы, связанной с телеконференциями. Дословно он звучал так: «Я бы посоветовал Вам почитать Станиславского. Телеконференции – это большое представление, шоу…». Если рекомендацию тогда я всерьёз не воспринял, то сегодня оцениваю её как весьма полезную.
Когда натыкаешься в Сети на очередное несдержанное восклицание «
Технические книжки – это не бессмертные произведения графа Толстого. К ним должен быть суровый, сугубо индивидуальный и безжалостный подход без какой-либо оглядки на чужое мнение. Прежде чем начать читать, возьмите листок бумаги, оптимально формата А4 – сложенный пополам, он удачно вкладывается в книгу, служа одновременно и закладкой. И запаситесь карандашом. Пользователям устройств для чтения электронных книг, к коим я тоже отношусь, необходимо освоить функции вставки в текст своих заметок.
Если «читалка» этого не позволяет, придётся всё-таки обратиться к бумаге или сменить устройство на более функциональное.
Теперь, по мере чтения, начинайте делать пометки в стиле «с. 11, это мнение плохо обосновано, потому что…», «стр. 25, хорошая мысль, применимо также в ситуации…». Очевидно, для пометок типа «у автора N выводы другие, но если обобщить…» потребуется немного больше времени.
Если, пролистав с полсотни страниц, вы не сделаете ни одной пометки, то можете смело закрывать сие произведение. В топку бросать, наверное, не надо, но поберегите своё время. Если же к концу прочтения вам хватит листа А4, исписанного убористым почерком, для всех пометок, то можете считать, что чтение прошло не зря. Ну а если одного листа не хватило… Тогда смело идите на свой любимый интернет-форум и там поделитесь с коллегами своими находками. Когда вместо малоинформативного «must have», используя все тот же испещрённый пометками лист, вы сможете передать пользу от прочитанного, коллеги будут вам чрезвычайно признательны за рекомендации и собственное сэкономленное время.Литература и программное обеспечение
Как вы знаете, в софтостроении, часто употребляется термин «(на)писать программу». Первые программы для ЭВМ не писали, а составляли. Составляли из машинных команд. Кодировали. Пробивали дырочки на картонных перфокартах. Затем появились языки высокого уровня, приближенные к естественным. Тогда программы стали именно писать. Сейчас, когда отрасль предпринимает попытки индустриализации, можно услышать, что программы вновь кодируют. И снова это связано с разделением труда: кодируют по спецификациям проектировщиков или по наитию пользовательских историй.
В литературе выражение «закодировать» пока не привилось, но налёт индустриальности уже коснулся и этой области человеческой деятельности. Миллионы журналистов ежедневно вставляют свои модули в разные форматы периодических изданий: от экспертных авторских колонок до банальной «джинсы» [131] . Здравицы и некрологи пишут загодя. Стереотипная массовая литература вроде карманных детективов и любовных романов поставлена на поток.
Разделение труда на «автора» и «кодировщика» в подобном процессе также присутствует. Даже если автор номинальный, издающий под своим брендом труд неизвестных литераторов, что, к сожалению, случается.
В итоге обнаруживаем немало сходства в процессе. Взглянем на классификацию создаваемых продуктов, плодов труда, приведённую в таблице.
Сходство усиливается. Обратите внимание на технологию использования продуктов. Исполнительной средой для программы является ЭВМ. Для литературного произведения в таковой роли выступает наш мозг. Глубокое погружение человека в процесс чтения соответствует 100 % загрузке процессора, а то и даже «зависанию». Откладывание книжки после пары просмотренных страниц говорит о несовместимости программы с текущей конфигурацией исполнительной среды.
Настало время посмотреть на архитектуру продуктов. Прежде всего, на степень ее абстрактности.
Существуют программные системы, представляющие собой весьма общее решение, по сути, каркас, фреймворк, который другой программист может использовать для решения своих задач. В литературе подобные фреймворки тоже встречаются. Как правило, на них ссылаются: «Это сюжет, основу которого составляет…». Наиболее известным разработчиком фреймворков является Вильям Шекспир. Базовая подсистема уровня ядра «Быть или не быть», обёрнутая собственным кодом писателя, присутствует практически в любом произведении, претендующем на глубину. Если придерживаться аналогий, Линус Торвальдс – Шекспир современного мира операционных систем на базе Linux.
В противоположность каркасам, встречаются самодостаточные программы, у которых, как говорится, не убавить и не прибавить. Законченные продукты решают поставленные пользователем задачи. Их надо заключать в рамочку хрестоматийных произведений, используя в соответствии с собственной программой обучения, например школьной.
Вспомним и о таком важном свойстве, как открытость архитектуры. Программы с открытой архитектурой позволяют создавать свои встраиваемые модули расширений [132] и легко интегрируются с другими программами. Не нарушая общей логики, совсем нетрудно взять пару ключевых героев и дописать эпизод из их жизни, не вошедший в книгу.
Монолитные же программы закрыты. Стоит потянуть за одну ниточку, как сдвинутся целые пласты. Только автору под силу внести дополнения в свое произведение. Дописать самостоятельный «приквел» или «сиквел» к «Войне и миру» – задача практически невыполнимая.
Наконец, существует как пакетная работа с программами, так и диалоговая. Пакетная обработка позволяет результат одной программы использовать для другой. Неважно, что главного героя увозят на тарелке инопланетяне. Заводим нового, помещаем его в старые декорации – вот и готово продолжение.
В диалоговом режиме все ненужные подробности скрывает красивый интерфейс, как правило, графический. Это не только комиксы и детские книги с обилием иллюстраций. Вполне можно обойтись текстовым режимом, лаконично излагая суть и делая сноски и ссылки для любознательных.
Хотя софтостроение довольно часто сравнивают со строительством домов, видимо, желая поскорее свести роль программистов к укладке готовых кирпичей и тем самым закрыть надоевшую проблему огромного числа просроченных или неудачных проектов, не бойтесь аналогий с писательским трудом. Ведь разработка программ совсем не означает необходимость всякий раз создавать «нетленку». В конце концов, хороший
Вместо послесловия, или Краткое изложение «Оснований»
В удивительные и непредсказуемые времена мы в испуге цепляемся за прошлое.
А. Азимов. «Край основания»
Вначале, как известно, было Слово™. И Слово™ содержало ровно столько байтов, сколько допускала архитектура ЭВМ. Поэтому 1 К не был равным 1 кбайт.
Из Слов™ стали составлять настолько скучные и однообразные на вид инструкции, что выполнять их могла только ЭВМ. Или самые упорные из составителей – в своем уме. И назвали эту технологию Программированием© в Машинных Кодах™. Вскоре парни, вооружённые Программированием в Машинных Кодах™ сделали Первую© Систему®. Далее значки торговых марок и копирайта я опускаю.
Когда парни сделали Первую Систему, их стали нагружать внесением в неё новых функций. Парни настолько были заняты этим делом, что у них едва хватало времени на чашку кофе и сигарету. Кроме того, они несколько состарились за работой и стали Старыми Чудаками.
И тут появились Молодые Парни, которым пришла в голову Мысль: можно вместо Машинных Кодов использовать их Мнемонику. Понятную человеку. Но, к сожалению, непонятную ЭВМ. Пришлось им в Машинных Кодах составлять вспомогательную программу – Транслятор, которая переводила Мнемокод в Машинный Код. На самом деле мысль Молодые Парни подслушали у Старых Чудаков, но тем, как мы помним, было не до реализации этой Мысли. И Молодые Парни, вооружённые Программированием в Мнемокодах, сделали Вторую Систему.
Когда Молодые Парни сделали Вторую Систему, их, как вы догадались, снова стали нагружать внесением в нее новых функций. Вначале парням удавалось вносить изменения так быстро, что оставалось время на несколько чашек кофе в день. И тогда их стали напрягать больше. Теперь Молодые Парни настолько были загружены, что у них опять едва хватало времени на чашку кофе и сигарету. Кроме того, они тоже состарились за работой и стали Старыми Чудаками.
Во время пития одной из чашек кофе у Старых Чудаков возникла мысль о том, что хорошо бы приблизить составление программы к написанию текста на человеческом языке. На Языке Высокого Уровня (ЯВУ). Но Чудаки были так заняты Второй Системой, что благородно позволили подслушать эту Мысль новым Молодым Парням, подсматривавшим за ними сквозь дырки в перфокартах.
Молодые Парни поднатужились и составили Транслятор с языка, похожего на математическую запись формул. Его так и назвали: Фортран – ФОРмуло-ТРАНслятор. Вооружённые Фортраном, Молодые Парни сделали Третью Систему. Но не успели они, быстренько добавив в Систему новые функции, сесть за кофе и партию в преферанс, покуривая в форточку подсобки, как их снова сильно напрягли. И снова стали они Старыми Чудаками. Да, чуть не забыл: в соседней комнате другие Молодые Парни и Девушка создали другой Транслятор, КОБОЛ – Как бы Описания Бизнес-правил… Ой, ладно. Они тоже делали Третью Систему, но с другого боку.
Надо сказать, что Старые Чудаки с Фортраном придумали такую вещь, как типы переменных по умолчанию. И все переменные, начинающиеся на
Третья Система оказалась такой живучей, что до сих пор можно увидеть объявления о поиске ну-Очень-Старых-Чудаков для внесения в нее изменений.
Очередные Молодые Парни стали кривить лица и указывать на сложность ЯВУ и несовершенство Трансляторов. Покривившись, они приступили к созданию более простых, ясных и надёжных ЯВУ, как им тогда казалось. Четвертую Систему парни начинали делать на C, а прикладную часть к ней – на Паскале. А сделав, как водится, превратились в Старых Чудаков. Причём одни Старые Чудаки так и остались на C, а другие потом решили добавить к названию два плюса. Третьи, поэкспериментировав с приставками «Турбо», вообще изменили название в пользу Дельфийского Оракула.
Следует вспомнить, что Один Умный Старый Чудак из Швейцарии потом продолжил создавать Следующие Системы. Но его упорно не замечали. И не потому, что его Системы были плохи. А потому, что все были по горло заняты внесением новых функций в Четвертую Систему.
Народу, вносящего изменения, все прибывало. Началось Вавилонское столпотворение ЯВУ и Подходов к Проектированию Программ. Каждый Молодой Парень считал свой ЯВУ лучшим, а Подход – единственно правильным. Но, сделав свою собственную Четвертую Систему, каждый парень становился очередным Старым Чудаком и неизбежно погрязал в добавлении в нее новых функций.
Наконец, Большие Дяди сказали себе, что пора бы навести Как бы Порядок в этом Творческом Бардаке. И стали вкладывать много денег для создания Единственно Правильной Четвертой-с-половиной Системы. Она не должна была зависеть от типа ЭВМ: единожды написанная на ЯВУ программа могла бы работать на любой другой ЭВМ. А чтобы новые Молодые Парни не создавали хаос, Большие Дяди создали свой Стандарт на ЯВУ и всё, что вокруг. На практике же оказалось, что однажды написанная программа должна быть отлажена везде, где её планируют запускать. Ну а чтобы другим парням и чудакам было не обидно заниматься отладкой и без передышки вносить в Четвертую-с-половиной Систему изменения, назвали её просто «Кофе».
Когда Большие Дяди стали поднимать Большие Деньги на своей Четвертой-с-половиной Системе, то Другие Большие Дяди решили, что они не хуже. И тоже сделали Четвертую-с-половиной Систему. Но, поскольку название «Кофе» оказалось занято, а «Сигарета» явно не соответствовала маркетинговым концепциям, её назвали так, чтобы все были бы внутренне горды от одного только чувства того, что работают они с Великой Четвертой-с-половиной-и-ещё-Точка Системой.
Внесение изменений в Четвертые-с-половиной Системы стало занятием столь же скучным, как и предыдущие. Поэтому, чтобы Молодые Парни не чувствовали себя, по крайней мере сразу же, такими же Старыми Чудаками, им разрешили обзывать всех вносящих изменения в Четвертую (ту, что без половины, а тем паче в Третью) Систему Старыми-Чудаками-на-Одну-Букву.
И вот одни Старые Чудаки добавляют функции в Четвертую, Третью и даже Вторую Системы. Другие – в Четвертые-с-половиной Системы. А в перерывах на форумах и в блогах последние обзывают первых Одной Буквой.
Но, поскольку форумы и блоги открыты, за процессом наблюдают Самые Молодые Парни. И, видя это, им всё меньше хочется делать Пятую Систему. Во-
первых, надо «учиться, учиться и ещё раз учиться» и отнюдь не на трёхмесячных курсах, а во-вторых, застолбившие рынок Большие Дяди не собираются его ни с кем делить. Но и становиться Старыми Чудаками при Четвертой-с-половиной Системе, минуя стадию Молодых Парней, им тоже не особо хочется.
И тогда все хором – от Старых Чудаков Первой Системы до Самых Молодых Парней – сказали: в нашей отрасли кризис! А Старые Чудаки добавляют: застой, и света в конце тоннеля не видно. Рядом с ними Маргинальные Чудаки с искусственным интеллектом под мышкой, специализированными ЯВУ и ЭВМ, суперкомпьютерами, векторными вычислениями и прочей экзотикой стоят в сторонке от мейнстрима и посмеиваются над ловкостью, с которой им удалось обмануть всех, включая самих себя.
Литература
1.
2.
3.
4.
5.
6.
7.
8.
9.
10. Серия статей «Информационная система Ниеншанц» // Компьютер-Информ. 1997. № 13–15.
11.
12.
13.
14.
15. «Joint Strike Fighter Air Vehicle. C++ coding standards for the system development and demonstration program», Lockheed Martin Corporation, December 2006.
16.
17.
18.
19.
20.
21.
22.
23.
24. MDD. Разработка, управляемая моделями, IBM Developer Works, IBM, 2007.
Примечания
1
Электронная Вычислительная Машина, вдруг кто забыл, как назывались компьютеры в русском языке.
2
Числовое Программное Управление.
3
Научно-Исследовательский Институт.
4
Конструкторское Бюро.
5
Конструкторско-Технологический Центр.
Поделиться книгой: