Роберт Гласс всегда умел взглянуть на проблему свежим взглядом: и в своих книгах, и в колонке Loyal Opposition, которую он несколько лет вел в журнале IEEE Software. И хотя Роберту перевалило за семьдесят, он и сегодня не просто успевает за развитием современных технологий — он, кажется, лучше других понимает, что ждет нас в ближайшем будущем.

Любопытно, что многие высказывания Гласса кажутся очевидными, как только они высказаны, — скажем, мысль о том, что небольшое увеличение сложности исходной задачи (в алгоритме, в объеме спецификаций и т. п.) ведет к стопроцентному усложнению программ. Или фраза про то, что по ходу проекта всегда происходит взрывной рост требований из-за того, что проявляются подразумеваемые требования и их приходится записывать явным образом. По здравом размышлении все это кажется банальным, но о таких простых вещах нужно обязательно говорить во всеуслышание, чтобы программистам не нужно было прислушиваться к своим смутным ощущениям в поисках причин провала. Такие истины нужно вдалбливать еще во время обучения в университете, чтобы программисты понимали внутренние противоречия процесса разработки и знали, с какими трудностями им предстоит бороться.

Особого внимания заслуживает раздел «Заблуждения», так как наши заблуждения ограничивают нас даже больше, чем реалии окружающего мира. Мне кажется, что самое ценное наблюдение в этой части книги — развенчивание популярного мифа, гласящего, что якобы «нельзя управлять тем, что вы не можете измерить». К’мон, а что же тогда программисты делали все эти годы?!

6 Len Bass, Paul Clements, Rick Kazman, «Software Architecture in Practice»

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

С помощью «Software Architecture in Practice» можно получить очень хорошее представление об очень темном предмете. Книга битком набита практическими примерами, взятыми из различных предметных областей и оформленными в виде отдельных case studies: есть, скажем, описание системы с повышенными требованиями к безопасности, описание сильно распределенной системы, пример перехода от приложения к семейству продуктов и т. д. Нельзя сказать, что книга построена вокруг какого-то единого подхода к созданию программных архитектур, но, может быть, это и к лучшему — вместо «единственного правильного метода» читатель получает множество практических советов и рекомендаций. Видимо, авторы полагают, что созданию хороших архитектур научить нельзя, что это может прийти только с опытом, и потому видят свою задачу в записи и распространении такого опыта. Той же задаче служит большое количество «отступлений мелким шрифтом», выражающих индивидуальные соображения авторов. Эти отступления представляют особую ценность, так как в них излагаются нетрадиционные приемы, которые применимы не всегда, но в некоторых случаях могут приносить дивиденды и потому должны входить в репертуар любого опытного программиста.

Наконец, во втором издании авторы добавили описание метода ATAM (Architecture Tradeoff Analysis Method), который может применяться для оценки программных архитектур уже созданных систем. Эта часть, наоборот, сугубо практична и предлагает конкретную последовательность шагов, с помощью которой можно оценить существующую архитектуру — не в абсолютных терминах, а с точки зрения заложенных в ней возможностей развития, ограничений и рисков.

7 Steve McConnell, «Software Project Survival Guide»

В последнее время появилось много хороших (и еще больше плохих) книг о том, как должен выглядеть промышленный программный процесс. Например, есть достойные труды об экстремальном программировании, agile processes и т. п. Однако я полагаю, что «Software Project Survival Guide» — лучшее введение в этот предмет. Во-первых, книга довольно короткая (три сотни страниц с большими полями); во-вторых, в ней изложены наилучшие практики последних лет по управлению проектами (эволюционный подход, независимое тестирование, рецензии программ, ежедневная сборка и т. п.); в-третьих, она основана на горячо любимом мною Microsoft Solutions Framework, хоть автор нигде о нем и не упоминает. Если бы эту книгу вручали начинающим программистам (а еще лучше — начинающим менеджерам), возможно, программирование было бы более цивилизованным занятием. Впрочем, и опытные разработчики найдут в «Software Project Survival Guide» немало интересного. Так, на меня в свое время произвел неизгладимое впечатление гениальный пассаж о статистических методах предсказания количества ошибок. Мне, конечно, много рассказывали про тестирование, но до этой книги я не подозревал, что общее количество ошибок в проекте можно оценить не только задним числом, но и по ходу проекта, причем для этого используются элементарные статистические трюки! Господи, почему мне про это никто в университете не рассказывал?!

Кстати, Макконнелл — единственный автор, представленный в моей десятке двумя книгами. Это, впрочем, не удивляет — по результатам опроса 1998 года он был третьим среди самых известных лиц в программной индустрии (домашнее задание — угадайте первых двух).


8 Jeffrey Ullman, «Elements of ML Programming»

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

Судя по всему, Джеффри Ульман, автор целого ряда прекрасных книг по информатике, прошел примерно такой же путь, только у него были другие друзья и он лучше меня разобрался в этом вопросе. Поэтому в середине 90-х он отложил в сторону свои любимые темы (компиляторы и базы данных) и написал простую и понятную сагу о языке ML. Так как ML — один из наиболее рафинированных представителей функционального программирования, по книге Ульмана можно составить представление не только об основных конструкциях, но и о принятом в ML «хорошем тоне», и даже в какой-то мере о том, чем все это лучше старого доброго императивного программирования.

9 Clemens Szyperski, «Component Software»

Клеменс Сиперски стал известен в академических кругах, будучи сотрудником института ETH в Цюрихе. В 1993 году он вместе с Никлаусом Виртом основал компанию Oberon Microsystems и начал работать над системой компонентного проектирования Oberon/F. Для тех времен это была поистине революционная технология (для сравнения — в том же году вышла первая действительно пригодная к использованию версия Visual Basic, 3.0). Правда, изящная среда разработки Oberon/F не сумела обрести популярность и стала не более чем развлечением для небольшого круга исследователей (кстати, та же судьба постигла практически все проекты Вирта после легендарного Паскаля).

Зато в процессе работы над этим проектом Сиперски придумал и убедительно описал в рассматриваемой книге картину светлого будущего, в котором программы составляются из крупных строительных блоков — компонентов. Поначалу на это никто не обращал внимания, так как всем казалось, что счастье уже не за горами, и принесет его стремительно развивавшееся ООП. Однако на практике повторного использования объектов добиться все не удавалось (от себя добавлю, что не удается и до сих пор), и тогда идеи Сиперски оказались востребованными. Технологии COM, CORBA, JavaBeans, а впоследствии и .NET, в создании которой Сиперски поучаствовал после перехода в Microsoft Research в 1999 году, как будто создавались по рецептам, описанным в этой классической книге. Сейчас она вышла уже во втором издании и используется во всем мире как учебник для университетских курсов по компонентному и распределенному программированию — везде, кроме России.

10 Andrew Appel, Jens Palsberg,  «Modern Compiler Implementation in Java»

Нельзя сказать, что про компиляторы ничего не пишут — скорее наоборот, пишут и очень много. Но написать хорошую книгу на эту тему трудно, ибо предмет фундаментальный, и получается либо излишне наукообразно (см., например, Dragonbook¹ и Мучника²), либо слишком поверхностно (например, вышедшее недавно на русском второе издание Хантера). Авторам удалось найти баланс между теорией и практикой: с одной стороны, в книге последовательно прослеживается создание полноценного компилятора (что, несомненно, заинтересует практиков), а с другой — описываются и более сложные приемы, требующие знания теории (оптимизация, распределение регистров, разметка графов).

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

Еще один комментарий. Я искренне завидую легкости, с которой Эппелю удалось клонировать свое сочинение: существуют полностью аналогичные по тексту книги, в которых компиляторы реализуются на C и ML. Чтобы выяснить, какая из них лучше, я договорился с коллегами в университете, что куплю все три варианта, а затем каждый выберет себе язык по вкусу. Я выбрал Java и впоследствии пожалел: оказалось, что элегантнее всего компилятор выглядит на ML (не иначе, на нем и писались все оригинальные примеры, а на остальные языки примеры переводили более или менее механически). Именно с этой книги началось мое недолгое знакомство с функциональными языками.


Вместо заключения

К сожалению, у этой статьи есть один существенный недостаток: если предположить, что описанные здесь книги вас заинтересовали и вы захотите купить всю десятку для своей домашней библиотеки, то ради сей благой цели вам придется изыскать около $400. Понятно, что для российского программиста (а уж тем более российского студента) это слишком дорогое удовольствие, так что мои дифирамбы этим книгам могут быть восприняты неадекватно.

Поэтому я обратился к руководителям крупнейших российских издательств c письмом, в котором кратко сформулировал достоинства вышеупомянутых книг и попросил ответить, не планируется ли включить какую-либо из них в план издательства по переводу. Я обязательно расскажу о результатах опроса (если, конечно, кто-нибудь мне ответит) и надеюсь, что в ближайшее время у самого широкого круга российских читателей появится возможность познакомиться с этими замечательными книгами.

1 Alfred V. Aho, Ravi Sethi, and Jeffrey D. Ullman, «Compilers: Principles, Techniques and Tools» (так называемая Red Dragon Book), или Alfred V. Aho, and Jeffrey D. Ullman, «Principles Of Compiler Design» (так называемая Green Dragon Book). Обычно под Dragon Book понимают все же «красную» книгу, поскольку она является переработанной версией «зеленой». — Прим. ред.
2 Steven Muchnik, «Advanced Compiler Design and Implementation». — Прим. ред.