Книга «Программист-прагматик
Программист-прагматик (англ. The Pragmatic Programmer: From Journeyman to Master) — книга Эндрю Ханта и Дэвида Томаса, посвящённая методологии и философии разработки программного обеспечения. Впервые опубликована в 1999 году издательством Addison-Wesley. Книга считается классическим трудом в области инженерии программного обеспечения, предлагающим практические советы по повышению эффективности работы программиста, управлению сложностью кода и профессиональному развитию.
История создания
Авторы, Эндрю Хант и Дэвид Томас, к моменту написания книги имели многолетний опыт консалтинга в области разработки ПО. Они заметили, что многие успешные программисты обладают схожими привычками и подходами, которые не описаны в академической литературе. Книга была задумана как сборник эмпирических правил («прагм»), основанных на реальном опыте, а не на теоретических моделях. Первое издание вышло в 1999 году и быстро завоевало популярность в профессиональном сообществе. В 2019 году, к 20-летию, вышло второе, значительно переработанное издание (англ. The Pragmatic Programmer: Your Journey to Mastery), в котором авторы обновили примеры, учли изменения в технологиях (облачные вычисления, микросервисы, современные языки) и добавили новые главы.
Основные идеи и философия
Книга построена не как учебник по конкретному языку или технологии, а как сборник принципов, применимых в любом контексте разработки. Ключевая метафора — «программист-прагматик» как ремесленник, который постоянно совершенствует свои инструменты и методы.
Принцип «Не оставляй сломанных окон»
Один из центральных принципов книги — не допускать ухудшения качества кода. Если в коде найдена небольшая ошибка или неоптимальное решение (сломанное окно), её следует исправить немедленно, не откладывая. Игнорирование мелких дефектов, по мнению авторов, ведёт к постепенной деградации всей системы, так как программисты привыкают к низкому качеству и перестают его замечать.
Принцип DRY (Don’t Repeat Yourself)
Принцип DRY формулируется как «каждая часть знания должна иметь единственное, непротиворечивое, авторитетное представление в системе». Авторы различают дублирование кода (очевидное копирование) и дублирование знаний (когда одна и та же бизнес-логика или правило выражены в разных местах разными способами). Нарушение DRY, по их мнению, — главная причина сложности сопровождения и появления ошибок.
Принцип «Ортогональность»
Ортогональность в контексте разработки означает, что изменения в одном компоненте системы не должны вызывать побочных эффектов в других. Авторы рекомендуют проектировать модули с минимальными связями (low coupling) и высокой внутренней связностью (high cohesion). Практическим следствием является использование небольших, независимых функций и классов, а также изоляция внешних зависимостей (баз данных, библиотек) за интерфейсами.
Принцип «Не повторяйся с комментариями»
Код должен быть самодокументируемым. Авторы утверждают, что комментарии к коду должны объяснять почему сделано то или иное решение, а не что делает код. Если код написан неясно, его следует переписать, а не дополнять комментариями. Комментарии, которые дублируют логику кода, со временем устаревают и становятся дезинформацией.
Структура и содержание
Книга состоит из нескольких тематических разделов, каждый из которых содержит конкретные советы и упражнения. Второе издание (2019) включает 70 советов (tips) и 52 упражнения.
Раздел 1: Прагматическая философия
В этом разделе излагаются базовые принципы: ответственность за свой код (нельзя сваливать ошибки на других или на инструменты), готовность к изменениям (гибкость), умение оценивать риски. Авторы вводят понятие «каменный суп» — метафору постепенного внедрения улучшений, когда сначала делается небольшой, но полезный шаг, который мотивирует команду на дальнейшие изменения.
Раздел 2: Прагматический подход
Рассматриваются вопросы управления проектами и кодом. Ключевые темы:
- Управление сложностью: разбиение задачи на мелкие, независимые части.
- Оценка времени: авторы предлагают методику «оценка по аналогии» и предупреждают о «ловушке точности» (когда программист пытается дать точную оценку на ранних этапах, когда данных недостаточно).
- Управление знаниями: ведение личной базы знаний (например, в виде вики или заметок), регулярное изучение новых технологий.
Раздел 3: Основные инструменты
Этот раздел посвящён эффективному использованию инструментов разработчика:
- Текстовый редактор: авторы настаивают на необходимости освоить один редактор (например, Vim или Emacs) на уровне, позволяющем выполнять операции без отрыва рук от клавиатуры.
- Системы контроля версий: использование VCS (Git, Mercurial) как обязательного инструмента для любого проекта, даже для личных экспериментов.
- Отладка: философия отладки как научного метода — формулировка гипотезы, её проверка, исключение переменных. Авторы предупреждают о «ловушке случайности» (когда баг воспроизводится нестабильно) и рекомендуют фиксировать все шаги.
- Автоматизация: использование скриптов для рутинных задач (сборка, тестирование, развёртывание).
Раздел 4: Прагматическая паранойя
Раздел посвящён защите от ошибок и непредвиденных ситуаций:
- Защитное программирование: проверка входных данных, использование утверждений (assertions), обработка исключений.
- Принцип «Не может случиться»: авторы утверждают, что если программист думает «этого не может произойти», то это обязательно произойдёт, и код должен быть к этому готов.
- Дизайн по контракту: чёткое определение предусловий, постусловий и инвариантов для каждого модуля.
Раздел 5: Гибкость и адаптация
Рассматриваются подходы к созданию гибких систем:
- Метаконфигурация: вынесение параметров (настроек, строк, бизнес-правил) из кода во внешние конфигурационные файлы или базы данных.
- Инверсия управления: использование фреймворков, которые вызывают код программиста, а не наоборот.
- Рефакторинг: как непрерывный процесс улучшения кода без изменения его внешнего поведения.
Раздел 6: Прагматические проекты
Заключительный раздел посвящён организации работы в команде:
- Непрерывная интеграция: автоматическая сборка и тестирование при каждом изменении кода.
- Тестирование: авторы различают модульные, интеграционные и регрессионные тесты. Особое внимание уделяется тестированию граничных условий и производительности.
- Управление требованиями: сбор требований как итеративный процесс, с использованием прототипов и пользовательских историй.
Критика и влияние
Книга получила широкое признание в профессиональном сообществе. Она входит в списки обязательной литературы для многих курсов по программной инженерии. Критики отмечают, что некоторые советы (например, по использованию конкретных редакторов или методик оценки) могут быть устаревшими или не универсальными, однако общая философия остаётся актуальной. Основная критика касается того, что книга ориентирована на индивидуального разработчика и не в полной мере учитывает проблемы крупных распределённых команд и корпоративной бюрократии.
Интересные факты
- Второе издание книги (2019) было написано с использованием принципов, описанных в первом издании: авторы вели разработку в Git, использовали непрерывную интеграцию и писали тесты.
- Книга переведена на более чем 20 языков, включая русский (издательство «Питер», 2002, 2020).
- Фраза «Don’t Repeat Yourself» (DRY) стала одним из самых цитируемых принципов в разработке ПО, хотя авторы не были первыми, кто её сформулировал, но популяризировали её.
Источники
- Хант Э., Томас Д. Программист-прагматик. Путь от подмастерья к мастеру. — СПб.: Питер, 2020. — 352 с. — ISBN 978-5-4461-1550-9.
- Hunt A., Thomas D. The Pragmatic Programmer: Your Journey to Mastery. — 2nd ed. — Addison-Wesley, 2019. — 352 p. — ISBN 978-0-13-595705-9.
- Рецензии в журналах «Computerworld» и «Dr. Dobb’s Journal» (1999–2000).
BFOmetr — база данных и аналитика по компаниям России.
На главную BFOmetr →