Десять программистских книг, которые потрясли мир, но все еще неизвестны в России
АрхивСписок Андрея Терехова, как и любой субъективный список, довольно спорен, но мы публикуем его, потому что книги, о которых он пишет, действительно хороши и, к сожалению, малоизвестны у нас.
Список Андрея Терехова, как и любой субъективный список, довольно спорен, но мы публикуем его, потому что книги, о которых он пишет, действительно хороши и, к сожалению, малоизвестны у нас. Сам Андрей несколько лет преподавал в СПбГУ, и тот факт, что его кафедра дала России единственную команду, побеждавшую на студенческой олимпиаде по программированию АСМ, вполне может служить достаточной рекомендацией составителю. — В.Г.
Перевод книг на русский язык — процесс парадоксальный: переводчики тратят уйму сил, издатель печатает тираж и рассылает его по магазинам, а книга почему-то обходится читателю в два-три раза дешевле, чем оригинал. Я точно знаю, что на каком-то звене этой цепочки нарушаются фундаментальные законы физики, но до сих пор не могу понять, где именно. Впрочем, если б не это чудо, нам пришлось бы покупать книги на компьютерную тематику по 50 долларов за штуку, а при таких ценах, согласитесь, особо не разгуляешься.
Поэтому я очень обрадовался, когда в середине 1990-х российские и украинские издательства начали одну за другой штамповать переводные книжки по программированию. Случилось это, надо сказать, своевременно: российские авторы уже почти ничего не писали, а издания конца 70-х—начала 80-х, осевшие в библиотеках, мягко говоря, перестали удовлетворять. Вскоре я собрал неплохую подборку трудов по программированию (пришлось даже купить книжный шкаф).
Однако полному счастью мешало одно досадное обстоятельство: мои представления о том, какие книги достойны перевода, почему-то сильно расходились с мнением издателей. И за последние десять лет мало что изменилось. При желании за это время можно было собрать богатейшую коллекцию книг о программировании на всех версиях Visual Basic, начиная с 3.0 и заканчивая VB.NET, но действительно полезные можно было пересчитать по пальцам. Поэтому я взял за правило при поездках за рубеж посещать книжные магазины. Кстати, не могу сказать, что в заокеанских магазинах процент приличных книг на эту тему выше, чем в России, но американцы, как обычно, берут не умением, а числом: в США объем полиграфической продукции таков, что всегда можно найти книги, заслуживающие внимания.
Покупка любой книги на Западе — это Поступок, последствия которого приходится тщательно взвешивать. Поэтому многие магазины поощряют чтение книг «не отходя от кассы» — ставят в салоне кресла, продают кофе и вовсе не настаивают на том, чтобы люди, перелистывающие томик, обязательно его купили! Но даже таких льготных условий, как показывает практика, мало, чтобы завлечь американцев в книжные магазины, а вот русские люди быстро превращаются в завсегдатаев. Сколько часов я провел в одном таком магазине во время командировки в США в 2000 году, только богу известно, — могу лишь сказать, что прочел не меньше десятка книг по программированию, а затем увез их в Россию целый чемодан.
Книги, что я привозил из заграницы, в целом были очень полезными. Некоторые из них я использовал для подготовки спецкурсов в университете, другие пригодились на работе, а третьи я читал для собственного удовольствия и саморазвития. Но поскольку многие из них до сих пор не переведены на русский, я чувствую себя обладателем бесценного, никому не известного знания. Поэтому я решил написать о своих любимых книгах и составил своеобразный хит-парад. Сразу оговорюсь: я высказываю личное, субъективное и, возможно, бесполезное мнение и представляю вам всю эту информацию «as is», а вы уж сами разбирайтесь, доверять моим оценкам или нет.
1 Tom DeMarco, Timothy Lister, «Peopleware»
Возможно, лучшее из того, что я когда-либо читал о психологии программирования. За двадцать лет с момента первой публикации книгу цитировали так часто, что большинство положений уже стали фольклором. Например, бессмертное наблюдение, что программисты, получающие одинаковую зарплату, могут отличаться по производительности в десять и более раз (для проверки этого утверждения авторы специально устраивали эксперименты по кодированию в течение десяти лет!); или утверждение, что основной фактор, от которого зависит производительность, — вовсе не организация процесса, а способности членов коллектива; или замечание о том, что основная функция менеджеров программных проектов — вовсе не заставлять людей работать, а создавать программистам идеальные условия для работы и впоследствии не мешать им, и т. д.
Однако самое интересное открытие авторов — это влияние удобства рабочего места на производительность труда. Оказалось, что организация офисного пространства, уровень шума, средняя частота отвлечений на телефонные звонки и т. п. влияют на процесс создания софта не меньше любого чисто программистского фактора. Поработав несколько лет в пресловутых «кубиках» и офисах с открытой планировкой, я ответственно заявляю, что у каждого программиста должен быть отдельная комната, с дверью, которую можно запереть на ключ, и телефоном, который можно переключить на автоответчик! К сожалению, для большинства программистов это по-прежнему голубая мечта. Наверное, все дело во всемирном заговоре менеджеров программных проектов.
2 Steve McConnell, «Code Complete»
Написанная в 1993 году, когда не существовало ни Java, ни .NET, ни рефакторинга, эта книга во многом устарела. Однако до сих пор, на мой взгляд, она остается лучшей книгой по software construction.
У меня сложилось свое мнение о том, почему на свете так мало толковых пособий по разработке программ: хорошие программисты не хотят писать книжек по software construction — для них это слишком очевидно (Стив Макконнелл — лишь исключение, подтверждающее правило), а неумехи в принципе не могут написать ничего хорошего и от досады переходят в лагерь противников, утверждая, что разработка ПО — вовсе не главное в программной инженерии, а главное — это Процесс Разработки По Великой и Непогрешимой Методологии (неважно по какой, лишь бы с большой буквы).
Это утверждение, конечно же, не выдерживает критики, ибо даже самый лучший на свете процесс разработки ничего не стоит, если у вас нет людей, умеющих писать связные программы, но почему-то в последнее время сторонников всесильных Методологий все больше и больше, а голос программистского разума звучит все глуше и глуше.
К счастью, у меня есть очень хорошая новость для тех, кто считает, что хорошее программирование начинается с хороших программистов: в июне ожидается выпуск второго издания (и я знаю как минимум одного потенциального покупателя).
3 Gerald Weinberg, «Psychology of Computer Programming»
Я, конечно, помню, что уже отдал свой голос «Peopleware» как лучшей книге о психологии программирования всех времен и народов, но сейчас я схитрю и проголосую во второй раз. В конце концов, это моя собственная статья, и никто не мешает мне менять правила по ходу игры.
Дело в том, что я сторонник теории распространения знаний через анекдоты. По моим представлениям, все это работает примерно так: программисты собираются в курилке или за кружкой пива и рассказывают друг другу «истории с полей» (у американцев это называется war stories).
Подход, разумеется, не научный, и эффективность передачи знаний таким образом немногим выше нулевой отметки. Однако все остальные способы почему-то еще хуже. Именно по этой причине такие книги, как «Вайнберг», остаются популярными и переиздаются через четверть века после первого издания без единого изменения в тексте! (Кстати, таких книг очень мало — я сумел вспомнить лишь Вайнберга, «Peopleware», ну и Брукса, конечно.)
Только подумайте — за прошедшие двадцать пять лет Фортран и Кобол перестали быть самыми продвинутыми языками программирования; подавляющее большинство современных программистов не знает, что такое писать в кодах, но вопросы, обсуждающиеся в «Psychology of Computer Programming», по-прежнему актуальны. Так что, покуда программирование остается созидательной областью человеческой деятельности, эта книга не покинет списка бестселлеров.
4 Steve Maguire, «Writing Solid Code»
Во времена моей юности продвинутые программисты любили щеголять термином defensive programming (защитное программирование). Он был как пропуск в высший свет: либо ты знаешь, что сие означает, и произносишь два красивых словечка, причмокивая губами и закатывая глаза (тогда ты, несомненно, крутой программист), либо удивленно хлопаешь ресницами, и тогда ты зеленый ламер. Вот только в ответ на расспросы «знатоки» отделывались общими словами про вселенскую полезность assert’ов и проверки переданных в функцию параметров. Короче, все что-то слышали про defensive programming, но никто про это толком рассказать не мог.
Так было до тех пор, пока за дело не взялся Стив Магвайр, программистский гуру из Microsoft, успешно работавший над такими продуктами, как Word и Excel на платформах Windows и Macintosh. В книге отражен бесценный опыт нескольких поколений программистов, отважно сражавшихся со своими и чужими программами на языке С — языке, прославившемся невероятным количеством разбросанных тут и там грабель. «Writing Solid Code» учит, как на эти грабли не наступить. Многие программисты скажут, что книга давным-давно устарела, и будут по-своему правы — нынешние языки программирования неуклонно движутся в сторону усиления статического контроля типов и тем самым оставляют все меньше места для случайных синтаксических ошибок. Но и это не панацея, так как никакой компилятор никогда не отследит off-by-one errors и не заставит программистов избегать рискованных трюков. Наверное, именно по этой причине в Microsoft все еще рекомендуют «Writing Solid Code» всем новоприбывшим разработчикам.
Нужно сказать, что защитное программирование так и не выросло до уровня всеобъемлющей парадигмы (как, например, структурное программирование или ООП) и по-прежнему находится на периферии программистских знаний. Тем не менее, некоторые идеи из этого подхода были реанимированы и переосмыслены в так называемом программировании по контракту, а значит лучшие времена защитного программирования еще впереди.
Роберт Гласс всегда умел взглянуть на проблему свежим взглядом: и в своих книгах, и в колонке 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»
Нельзя сказать, что про компиляторы ничего не пишут — скорее наоборот, пишут и очень много. Но написать хорошую книгу на эту тему трудно, ибо предмет фундаментальный, и получается либо излишне наукообразно (см., например, Dragonbook1 и Мучника2), либо слишком поверхностно (например, вышедшее недавно на русском второе издание Хантера). Авторам удалось найти баланс между теорией и практикой: с одной стороны, в книге последовательно прослеживается создание полноценного компилятора (что, несомненно, заинтересует практиков), а с другой — описываются и более сложные приемы, требующие знания теории (оптимизация, распределение регистров, разметка графов).
Отзывы о книге встречаются разные — от восторженных до разгромных, но полагаю, в этом повинна не столько она, сколько читающая ее аудитория. Похоже, читатели подходят к прочтению этого труда со сложившимся набором базовых концепций. Если сей набор совпадает с аппаратом, используемым авторами, — читатели довольны; если нет, то всем не повезло. Единственное, в чем читатели сходятся, — это раздражающе большое количество опечаток.
Еще один комментарий. Я искренне завидую легкости, с которой Эппелю удалось клонировать свое сочинение: существуют полностью аналогичные по тексту книги, в которых компиляторы реализуются на 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». — Прим. ред.
