|
|
Десять программистских книг, которые потрясли мир, но все еще неизвестны в России
Андрей Терехов
Список Андрея Терехова, как и любой субъективный список, довольно спорен, но мы публикуем его, потому что книги, о которых он пишет, действительно хороши и, к сожалению, малоизвестны у нас. Сам Андрей несколько лет преподавал в СПбГУ, и тот факт, что его кафедра дала России единственную команду, побеждавшую на студенческой олимпиаде по программированию АСМ, вполне может служить достаточной рекомендацией составителю. - В.Г. Перевод книг на русский язык - процесс парадоксальный: переводчики тратят уйму сил, издатель печатает тираж и рассылает его по магазинам, а книга почему-то обходится читателю в два-три раза дешевле, чем оригинал. Я точно знаю, что на каком-то звене этой цепочки нарушаются фундаментальные законы физики, но до сих пор не могу понять, где именно. Впрочем, если б не это чудо, нам пришлось бы покупать книги на компьютерную тематику по 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» всем новоприбывшим разработчикам. Нужно сказать, что защитное программирование так и не выросло до уровня всеобъемлющей парадигмы (как, например, структурное программирование или ООП) и по-прежнему находится на периферии программистских знаний. Тем не менее, некоторые идеи из этого подхода были реанимированы и переосмыслены в так называемом программировании по контракту, а значит лучшие времена защитного программирования еще впереди. 5 Robert Glass, «Facts and Fallacies of Software Engineering»Роберт Гласс всегда умел взглянуть на проблему свежим взглядом: и в своих книгах, и в колонке 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 года он был третьим среди самых известных лиц в программной индустрии (домашнее задание - угадайте первых двух).
|