- Название: “Программист-прагматик” (1-е издание)
- Автор: Эндрю Хант, Дэвид Томас
- Начало чтения: 29.08.25
- Конец чтения: 05.09.25
Слышал много положительных отзывов про эту книгу. Лет 5 назад даже начинал читать, но забросил. Поводом для повторного прочтения стала рекомендация Александра Пахомова, автора канала apakhomov.
Читал в формате fb2 на своей новой электронной книжке Meebook M7. Хотел понять, насколько комфортно будет читать около-техническую литературу в fb2 с 7-ми дюймового экрана. Читалка показала себя отлично; главный плюс — её очень удобно брать её везде с собой и читать в дороге. Исключение составили лишь съехавшие картинки и блоки кода (что было ожидаемо) — благо их было немного.
Читал первое издание, поскольку только его смог найти в fb2. Будет поводом прочитать и второе, вышедшее спустя 20 лет. Возможно, даже в бумаге, с красивейшей обложкой.
В качестве цели на проработку книги я поставил себе ознакомление с прагматической философией разработки ПО и интеграцию её идей в свой mindset и рабочий процесс.
Книга мне понравилась. Читается очень легко. Я бы отнес её скорее к разделу вдохновляющих, нежели обучающих книг. Не нашел в ней каких-либо откровений для себя, но получил подтверждение правильности моих мыслей и подхода к работе. Смело считаю себя программистом-прагматиком.
Из минусов могу отметить скучную середину (5-7 главы) и небольшое количество явно устаревших примеров и мыслей.
Рекомендую прочитать начинающим специалистам для получения нравственного ориентира и модели поведения, к которой стоит стремиться, чтобы стать настоящим мастером.
Несмотря на то что кардинально новых идей я для себя не открыл, отметил несколько важных моментов.
Глава 1. Прагматическая философия 
[У программистов-прагматиков] Уверенность рождается из опыта
Кайдзен (Kaizen) — философия непрерывного внедрения мелких усовершенствований.
Всегда нужно представлять варианты решения проблемы вместо отговорок.
Интересная история про суп из камней. Быть катализатором изменений. Начинать делать по чуть-чуть. Остальные подтянуться, когда увидят результаты.
Нужно сделать качество одним из требований. Четко обговаривать, насколько качественным должен быть разрабатываемый продукт исходя из сроков.
Не нужно портить хорошую программу бесконечной шлифовкой. Дать программе время побыть неидеальной. Возможно, она не станет идеальной никогда.
Знания и опыт — самые важные профессиональные активы. Но это истекающие активы, поскольку они со временем устаревают и становятся менее актуальными.
Прямая аналогия портфеля знаний как портфеля инвестиций. Советы:
- Инвестировать регулярно
- Диверсифицировать
- Сбаланировать (консервативные и высокорисковые активы)
- Купил дешевле продал дороже. Это про то, чтобы учить перспективные технологии заранее
- Регулярно пересматривать портфель
Глава 2. Прагматических подход
DRY:
Каждый фрагмент знания должен иметь единственное однозначное представление в системе
Окончательных решений не существует. Нужно быть готовым к тому, что в любой момент всё может поменяться и изменение должно требовать как можно меньше переделок.
Тут я окончательно убедился в том, что архитектура и проектирование ПО — это очень тонкие материи. Никто не знает, как сделать правильно. Есть лишь набор правил, которые могут помочь, но ничего не гарантируют.
Глава 3. Походный набор инструментов
Хорошая аналогия между разработкой ПО и стрельбой. Чтобы определить цель либо делаем точные расчеты, либо стреляем трассирующими патронами. Изначально я воспринял её в контексте умения положиться на интуицию в противовес долгому планированию и расчетам. Авторы сделали акцент на необходимости собирать отдельные компоненты системы вместе как можно раньше.
Инструменты — это средство усиления таланта. Чем лучше владеешь инструментами, тем больше можешь сделать. Необходимо регулярно приобретать новые инструменты. Приобретения должны исходить из существующей необходимости (имхо спорно, т.к. иногда сложно определить необходимость).
Довольно большой блок про plain text. Простой текст — самый лучший способ хранения данных в долгосрочной перспективе. Простой текст переживёт любую программу, породившую его. Очень близкие мне идеи
Текст — это сырье для программирования. Крайне важно уметь максимально эффективно работать с ним. Лучше использовать один текстовый редактор на максимум для редактирования всего текста, чем отдельные инструменты для кода, документации и тд
Прагматики обрабатывают тексты программ так, как столяры придают форму деревянным заготовкам
Очень много красивых аналогий со столярным делом. Нравится
Глава 4. Прагматическая паранойя
Невозможно написать совершенную программу
Корректная программа — та, которая делает то, на что претендует.
Исключения — для исключительных случаев. Не найден файл, который должен быть — исключение. Не найден файл, путь до которого ввел пользователь, — обычная ситуация
Подпрограмма, которая берёт ресурс, должна его освободить. Вопрос не конкретной реализации, а объединения кода в логические блоки
Глава 5. Гибкость против хрупкости
По умолчанию никто не думает о параллельном выполнении, хотя зачастую оно возможно и может ускорить приложение. Аналогия с приготовлением коктейля. Нужно анализировать последовательность действий и строить UML-диаграммы
Глава 6. Пока вы пишете программу
Ошибочно думать, что перевод мыслей в код — это механическая работа.
Пример: написали код; “вроде бы работает” — это программирование в расчете на обстоятельства. Плохой подход, который порождает ненадежные решения.
Если в процессе разработки мы исходим из каких-либо предположений или допущений, их важно явно фиксировать в коде.
Программирование — это садоводство, а не строительство. Код разрастается, его нужно “постригать”, “пересаживать кусты” и тд. В отличие от строительства, в котором есть четкие этапы. Очень хорошая аналогия
Рефакторить нужно как можно раньше и как можно чаще. Не существует другого времени кроме настоящего.
Глава 7. Перед тем, как начать проект
При принятии решения важно оценивать, обратимо ли оно.
Если требования меняются и дополняются по ходу проекта это важно отслеживать и подсвечивать заказчикам.
При проектировании и описании контракта нет смысла продумывать его сразу до мельчайших подробностей. Требования всегда могут измениться
Глава 8. Прагматические проекты
При столкновении с сложной проблемой делать шаг назад и думать:
- Зачем это делаем?
- Решаешь ли проблему или отвлекаешься на мелочи?
- Что делает проблему сложной для решения?
Некоторые вещи проще и лучше сделать, чем описывать. Как можно описать процесс завязывания шнурков?
Этапы сбора требований, разработки и тестирования — это не изолированные этапы. Это разные части одного процесса. Сначала собрать все требования до мельчайших деталей, прописать спеку и только потом писать по ней код втупую — неправильный подход. Перевод в код — это не механическая работа. Она должна замыкать цикл обратной связи к сбору требований.
Формальные методы — лишь один из инструментов. Не быть их рабом и критически оценивать каждый подход как инструмент. Дорогие инструменты не всегда создают лучшие решения
Организуйте команду на основе функциональности, а не должностных обязанностей
Про тестирование.
Нужно тестировать безжалостно. Не поддаваться искушению тестировать, избегая корнер-кейсов. Тестировать часто, как можно раньше и автоматически. Разные виды тестов предназначены для отлова багов разного размера.
Как тестировать сами тесты? Ответ: пытаться намеренно сломать их вручную. Авторы описывают концепцию мутационного тестирования, хоть и не используют этот термин напрямую.
Тестовое покрытие нужно измерять по числу возможных состояний, а не по строкам. Пример: тестирование строки с = a / b.
Про документацию.
Полезно вести глоссарий проекта.
Воспринимать естественный язык как один из языков программирования. Хорошая документация должна быть встроена в проект, а не прикручена сверху отдельно.
Мы хотим, чтобы вы гордились правом собственности. …. Ваша подпись должна стать признанным знаком качества. Люди должны увидеть ваше имя в заголовке программы и рассчитывать на то, что она будет солидной, хорошо составленной, проверенной и документированной. Это должна быть поистине профессиональная работа. Написанная настоящим профессионалом. Прагматиком-программистом.
books