ения (и ответы к ним) как правило, несложные, тогда как Вопросы для обсуждения более замысловаты. Для того чтобы передать свой образ мышления, авторы включили свои собственные ответы к упражнениям в приложение В, но лишь некоторые из упражнений имеют единственное корректное решение. Вопросы для обсуждения могут стать основой для групповых дискуссий или написания эссе на углубленных курсах программирования.
Исходные тексты программ и другие ресурсы
Большинство программ, представленных в этой книге, извлечены из компилируемых исходных файлов, которые можно загрузить с web-сайта www.pragmaticprogrammer.com.
Ваши отклики
Авторам книги интересны ваши отклики. Комментарии, предложения, замеченные в тексте ошибки и проблемы в приведенных примерах всячески приветствуются. Наш электронный адрес:
ppbook@pragmaticptogrammer.com.
Благодарности
Когда мы начали писать эту книгу, у нас и в мыслях не было, сколько коллективных усилий необходимо для ее выпуска в свет.
Издательство Addison-Wesley было как всегда великолепно, пригласив пару начинающих хакеров и показав авторам весь процесс издания книги – от идеи до оригинал-макета. Авторы выражают благодарность Джону Уэйту и Меере Равиндирану за поддержку в начале работы над книгой, Майку Хендриксону, редактору-энтузиасту (и оформителю обложки!), Лоррейн Ферье и Джону Фуллеру за помощь в производстве, а также неутомимой труженице Джулии Дебаггис, связавшей нас воедино.
Затем наступил черед рецензентов. Это Грег Эндресс, Марк Чиэрс, Крис Кли-лэнд, Алистер Кокбэрн, Уорд Каннингхэм, Мартин Фаулер, Тхапг Т. Зиан, Роберт Л.
Гласе, Скотт Хеннингер, Майкл Хантер, Брайан Кирби, Джон Лакос, Пит Макбрин, Кэри П. Моррис, Джаред Ричардсон, Кевин Рулэнд, Эрик Старр, Эрик Ваут, Крис Ван Вик и Дебора Зуковски. Без их заботливых комментариев и ценных советов эта книга читалась бы хуже, была бы менее точной и в два раза длиннее. Благодарим их за уделенное нам время и мудрость.
Второе издание этой книги существенно выиграло за счет пристальных взоров читателей. Благодарим Брайана Блэнка, Пола Боула, Тома Экберга, Брента Фулгэ-ма, Луи Поля Эбера, Хенка-Яна Ульде Лоохюса, Алана Лунда, Гарета Маккофана, Иошики Шибату и Фолькера Вурста за найденные ошибки и деликатность, проявленную при указывании на них авторам.
В течение многих лет мы работали с большим количеством продвинутых клиентов, от них мы набирались опыта, который и описали в этой книге. Недавно мы имели счастье работать с Питером Герке над несколькими проектами. Мы благодарны ему за его поддержку и энтузиазм.
При издании данной книги использовались программные продукты LaTex, pic, Perl, dvips, ghostview, ispell, GNU make, CVS, Emacs, XEmacs, EGCS, GCC, Java, iContract и SmallEiffel, оболочки Bash и zsh в операционной среде Linux. Поражает тот факт, что все эта груда программного обеспечения распространяется абсолютно бесплатно. Авторы говорят «спасибо» тысячам программистов-прагматиков, создавших эти продукты и передавших их нам. Отдельно хотелось бы поблагодарить Рето Крамера за его помощь в работе с iContract.
И последнее, но оттого не менее важное: авторы в огромном долгу перед своими семьями, которые не только смирились с поздним засиживанием за компьютером, огромными счетами за телефонные разговоры и постоянным беспорядком, но и благородно время от времени соглашались прочесть то, что написали авторы. Благодарим их за то, что они не давали нам спускаться с небес на землю.
Энди Хант
Дэйв Томас
Глава 1Прагматическая философия
Что отличает программистов-прагматиков? Мы полагаем, что это склад ума, стиль, философия подхода к существующим проблемам и их решениям. Прагматики выходят за пределы сиюминутной проблемы, всегда стараются рассмотреть ее в более широком контексте, осознать общую картину происходящего. В конце концов, как можно быть прагматиком вне широкого контекста? Как приходить к интеллектуальным компромиссам и принимать взвешенные решения?
Другим ключом к успеху прагматиков является то, что они берут на себя ответственность за все, что они делают; это обсуждается ниже в разделе «Мой исходный текст съел кот Мурзик». Будучи ответственными, прагматики не сидят, сложа руки, глядя на то, как их проекты погибают из-за небрежного отношения. В разделе «Программная энтропия» говорится о том, как сохранить проекты в первоначальном виде.
Большинство людей с трудом воспринимают изменения: иногда по понятным причинам, иногда в силу старой доброй инерции. В разделе «Суп из камней и сварившиеся лягушки» рассматривается стратегия провоцирования изменений, а также (для равновесия) предлагается поучительная сказка о некоем земноводном, которое не учло опасностей, таящихся в постепенном изменении.
Одним из преимуществ понимания контекста, в котором вы работаете, является более легкое осознание того, насколько хорошими должны быть создаваемые программы. Иногда «почти идеальность» является единственно возможным вариантом, но зачастую приходится идти на компромиссы. Этот аспект исследуется в разделе «Приемлемые программы».
Конечно, необходимо обладать обширной базой знаний и опыта, чтобы все это одолеть. Обучение представляет собой непрерывный и продолжительный процесс. В разделе «Портфель знаний» обсуждаются некоторые стратегии поддержания стремления к обучению.
Разумеется, никто из нас не работает в безвоздушном пространстве. Все мы проводим большое количество времени в общении с другими людьми. В разделе «Общайтесь!» перечислены способы, как сделать это общение более эффективным.
Прагматическое программирование ведет свое начало от философии прагматического мышления. В данной главе приводятся основные положения этой философии.
1Мой исходный текст съел кот Мурзик
Страх показаться слабым есть величайшая из всех слабостей.
Одним из краеугольных камней прагматической философии является идея принятия ответственности за себя и за свои действия с точки зрения карьерного роста, проекта и каждодневной работы. Программист-прагматик принимает на себя ответственность за свою собственную карьеру и не боится признаться в неведении или ошибке. Конечно, это не самый приятный момент программирования, но иногда подобное случается даже с самым лучшим из проектов. Несмотря на тщательное тестирование, хорошее документирование и основательную автоматизацию, все идет не так как надо. Выпуски программ запаздывают. Возникают непредусмотренные технические проблемы.
Подобные вещи случаются, и мы пытаемся справиться с ними настолько профессионально, насколько это возможно. Это означает необходимость быть честным и непосредственным. Мы можем гордиться нашими способностями, но мы должны быть честными, говоря и о наших недостатках – нашем неведении и наших ошибках.
Принятие ответственности
Ответственность – это то, на что активно соглашаются. Вы связываете себя обязательством, чтобы гарантировать, что нечто делается правильно, но ваш непосредственный контроль над каждым аспектом делаемого не является необходимостью. В дополнение к тому, что вы делаете все от вас зависящее, необходимо анализировать ситуацию на предмет наличия неконтролируемых вами рисков. Вы имеет право не принимать на себя ответственность за невозможную ситуацию, или за ситуацию, риски в которой слишком велики. Вам придется сделать самоотвод, основанный на вашей собственной этике и оценках.
Если вы приняли на себя ответственность за результат, то вам придется за него перед кем-то отчитываться. Если вы делаете ошибку (как и все мы), признайте ее честно и попытайтесь предложить варианты исправления.
Не стоит перекладывать вину на кого-либо (или на что-либо) или выдумывать отговорки. Не стоит сваливать все на субподрядчика, язык программирования, менеджмент или коллег по работе. Все они могут сыграть свою роль в неудаче, но вашим делом является решение проблем, а не отговорки.
Если есть вероятность, что субподрядчик не справится со своими обязанностями, то у вас должен быть план на случай возникновения непредвиденных обстоятельств. Если жесткий диск выходит из строя, унося в небытие весь исходный текст, а у вас нет резервной копии, это ваша вина. Фраза «Мой исходный текст съел кот Мурзик», высказываемая вашему шефу, не решит возникшей проблемы.
Подсказка 3: Представьте варианты решения проблемы, а не варианты отговорок
Перед тем как подойти к кому-либо, чтобы высказать, почему что-либо не может быть сделано или уже сломалось, остановитесь и прислушайтесь к себе. Поговорите с резиновым утенком, стоящим на вашем мониторе, или с котом. Как звучит ваша отговорка, разумно или глупо? И как ее воспримет ваш шеф?
Смоделируйте разговор в уме. Что, вероятнее всего, скажет ваш собеседник? Спросит ли он: «А так вы пробовали?» или «А это вы учли?» Как ответить? Перед тем как пойти и сообщить плохие новости, может, попробовать что-то еще? Иногда вы просто знаете, что он собирается сказать, поэтому избавьте его от лишних забот.
Вместо отговорок представьте варианты решения проблемы. Не говорите, что это не может быть сделано, объясните, что может быть сделано для спасения ситуации. Может быть, взять да и выбросить исходный текст? Развивайте эти варианты, используя реорганизацию (см. «Реорганизация»). Стоит ли тратить время на разработку прототипа, чтобы определить лучший способ, который необходимо использовать (см. «Прототипы и памятные записки»)? Стоит ли внедрять более совершенные процедуры тестирования (см. «Программа, которую легко тестировать» и «Безжалостное тестирование») или автоматизации (см. «Вездесущая автоматизация»), чтобы предотвратить дальнейшие неудачи? Возможно, вам понадобятся дополнительные ресурсы. Не бойтесь спрашивать или признаться, что нуждаетесь в помощи.
Попытайтесь исключить неубедительные отговорки до того, как их озвучить. Если нужно, выскажите их сначала вашему коту. Ну а если ваш Мурзик возьмет вину на себя…
• Прототипы и памятные записки
• Реорганизация
• Программа, которую легко тестировать
• Вездесущая автоматизация
• Безжалостное тестирование
• Как вы отреагируете, когда кто-нибудь – кассир в банке, механик в автосервисе, или клерк придет к вам с подобными отговорками? Что в итоге можно подумать о них лично и об их фирме?