Общая информация
| Параметр | Значение |
|---|---|
| Автор | John Ousterhout |
| Год | 2018 (2-е издание 2021) |
| Страниц | 196 |
| Уровень | Intermediate |
| Издательство | Yaknyam Press |
| Рейтинг полезности | 5/5 |
О чём эта книга
A Philosophy of Software Design -- это компактная и глубокая книга о борьбе со сложностью в программном обеспечении. Ousterhout -- профессор Стэнфорда, создатель Tcl и распределённой системы хранения RAMCloud. Он преподаёт курс дизайна ПО и собрал свои наблюдения в эту книгу.
Главная ценность: Книга даёт принципиально другой взгляд на дизайн, чем Clean Code. Ousterhout аргументирует, что главный враг -- сложность, и предлагает конкретные стратегии борьбы с ней. 196 страниц -- ни одной лишней.
Структура книги
Природа сложности
Определение сложности: Сложность -- это всё, что делает систему трудной для понимания и модификации. Она проявляется в трёх формах:
| Симптом | Описание | Пример |
|---|---|---|
| Change Amplification | Простое изменение требует правок во многих местах | Изменение формата даты в 20 файлах |
| Cognitive Load | Нужно много знать, чтобы сделать изменение | Понимание 5 классов для добавления поля |
| Unknown Unknowns | Непонятно, что нужно изменить | Неочевидные побочные эффекты |
Причины сложности:
- Dependencies -- когда код нельзя понять изолированно
- Obscurity -- когда важная информация не очевидна
Deep Modules vs Shallow Modules
Центральная идея книги:
Deep Module (хорошо):
┌────────────────────────┐
│ Simple Interface │ <-- маленький интерфейс
├────────────────────────┤
│ │
│ Rich Functionality │ <-- много функциональности
│ │
│ │
└────────────────────────┘
Shallow Module (плохо):
┌────────────────────────────────────┐
│ Complex Interface │ <-- большой интерфейс
├────────────────────────────────────┤
│ Little Functionality │ <-- мало функциональности
└────────────────────────────────────┘
Примеры deep modules:
- Unix file I/O: пять функций (open, read, write, lseek, close) скрывают огромную сложность
- Garbage Collector: один вызов скрывает сложнейшие алгоритмы управления памятью
Примеры shallow modules:
- Java I/O: FileInputStream, BufferedInputStream, InputStreamReader -- три слоя обёрток
- Getter/Setter для каждого поля -- интерфейс дублирует реализацию
Стратегическое vs тактическое программирование
| Подход | Цель | Последствия |
|---|---|---|
| Тактическое | Заставить код работать быстро | Рост сложности, технический долг |
| Стратегическое | Создать хороший дизайн | Инвестиция времени (10-20% больше), окупается |
Информация: скрытие и утечка
Information Hiding -- модуль скрывает детали реализации за простым интерфейсом.
Information Leakage -- детали реализации просачиваются через интерфейс:
- Через параметры функции
- Через возвращаемые типы
- Через документацию (когда пользователь должен знать детали)
Комментарии
Ousterhout выступает за комментарии, что противоположно позиции Clean Code:
| Позиция Clean Code | Позиция Ousterhout |
|---|---|
| Код должен быть самодокументируемым | Код не может выразить высокоуровневый замысел |
| Комментарии = признак плохого кода | Комментарии = часть дизайна |
| Названия методов заменяют комментарии | Названия дополняются комментариями |
Какие комментарии писать:
- Interface comments -- что модуль делает (не как)
- Cross-module comments -- как модули взаимодействуют
- Why comments -- почему принято решение
Пять ключевых идей
1. Сложность -- главный враг
Не плохой код, не баги, не производительность. Сложность -- это то, что делает системы неуправляемыми. Все остальные проблемы -- следствия.
2. Deep Modules
Хороший модуль имеет простой интерфейс и богатую функциональность. Shallow modules (много интерфейса, мало функциональности) увеличивают сложность.
3. Стратегическое программирование
Инвестируйте 10-20% дополнительного времени в хороший дизайн. Тактическое "лишь бы работало" программирование создаёт технический долг, который потом стоит в разы дороже.
4. Define Errors Out of Existence
Лучший способ обработать ошибку -- сделать так, чтобы она не могла возникнуть. Дизайн, исключающий ошибочные состояния, проще дизайна, обрабатывающего их.
5. Дизайн происходит дважды
Всегда рассматривайте минимум два альтернативных подхода к дизайну. Первый вариант редко бывает лучшим.
Плюсы
- Краткость -- 196 страниц, каждая страница ценна
- Глубина мышления -- провокационные идеи, заставляющие переосмыслить привычки
- Deep Modules -- мощная метафора для оценки качества дизайна
- Контринтуитивность -- спорит с Clean Code, расширяя перспективу
- Практичность -- концепции применимы немедленно
Минусы
- Краткость -- иногда не хватает развёрнутых примеров
- Субъективность -- позиция по комментариям спорная
- Масштаб -- фокус на модулях и классах, мало о системной архитектуре
- Академичность -- примеры из университетских проектов, не из enterprise
Кому читать
- Всем разработчикам с 1+ годами опыта -- формирует правильное мышление о дизайне
- Тем, кто читал Clean Code и хочет альтернативную перспективу
- Инженерам, борющимся со сложностью в своих проектах
- Tech-лидам, проводящим code review
Кому НЕ читать
- Полным новичкам -- нужен опыт для оценки идей
- Тем, кто ищет конкретные паттерны проектирования систем
- Инженерам, ищущим материал для System Design интервью
Рекомендация: Обязательная книга. 196 страниц, которые можно прочитать за выходные и которые изменят ваш подход к дизайну. Прочитайте после Clean Code -- контраст между подходами Мартина и Ousterhout чрезвычайно полезен для формирования собственной позиции. Лучшее соотношение ценности к объёму среди всех книг в этом списке.