Источник
Code of Architecture — Recap
Обзор книги в четырёх выпусках книжного клуба CoA с участием архитекторов Т-Банка.
A Philosophy of Software Design
Авторы: John K. Ousterhout
Издательство: Yaknyam Press
Объём: 190 страниц
Философия борьбы со сложностью от Джона Остерхаута: глубокие модули, information hiding, strategic programming и red flags.
ОригиналО книге
"A Philosophy of Software Design" — одна из самых цитируемых современных книг о проектировании ПО. Джон Остерхаут, профессор Стэнфорда и автор Tcl/Tk, представляет философию борьбы со сложностью через правильную модуляризацию, скрытие информации и стратегическое мышление.
Книга возникла из курса CS 190 в Стэнфорде, где студенты проектировали и review'или реальные программные системы. Это сборник практических принципов, выведенных из анализа тысяч студенческих проектов.
Детальный обзор
Review Part I
Подробный разбор первых глав: сложность, тактическое vs стратегическое программирование.
Часть 1: Природа сложности (главы 1-6)
Природа сложности
Симптомы сложности:
Причины сложности:
Связи между модулями
Неясность намерений кода
Формула:
Complexity = Σ (cₚ × tₚ)
где c — сложность компонента, t — время работы с ним
Тактическое vs Стратегическое программирование
Тактическое ❌
- "Главное — чтобы работало"
- Быстрые патчи и хаки
- Накопление технического долга
- Локальная оптимизация
Стратегическое ✅
- "Хороший дизайн = рабочий код"
- Инвестиции 10-20% времени в дизайн
- Проактивное устранение сложности
- Глобальная оптимизация
Детальный обзор
Review Part II
Глубокий разбор глав 7-11: уровни абстракции, перемещение сложности, исключения.
Часть 2: Модули и абстракции (главы 7-11)
Глубокие vs Мелкие модули
Deep Module ✅
Маленький интерфейс, много возможностей
Shallow Module ❌
Большой интерфейс, мало возможностей
Примеры глубоких модулей: Unix file I/O (5 системных вызовов), сборщик мусора (нулевой интерфейс). Shallow: Java I/O классы, множество exceptions.
Information Hiding
Каждый модуль должен инкапсулировать знания о дизайне, представляя наружу минимальный интерфейс.
❌ Information Leakage — детали реализации видны снаружи
❌ Temporal Decomposition — разбиение по времени выполнения
Different Layer, Different Abstraction
На каждом уровне системы должны быть свои абстракции. Pass-through методы — признак проблем.
✅ Pull Complexity Downward
Перемещайте сложность вниз — в реализацию, а не в интерфейс
Define Errors Out of Existence
Вместо бросания исключений — проектируйте API так, чтобы ошибочные состояния были невозможны. Пример: unset() в Tcl не бросает исключение для несуществующей переменной — это делает код проще.
Часть 3: Комментарии и документация (главы 12-16)
Почему комментарии важны
Комментарии не дублируют код — они описывают абстракции, которые код не может выразить.
• Interface comments — контракт модуля
• Implementation comments — "что" и "почему"
• Cross-module comments — связи между модулями
Comments First
Пишите комментарии перед кодом. Это помогает:
- Продумать дизайн до реализации
- Определить правильные абстракции
- Обнаружить проблемы в дизайне рано
- Сохранить мотивацию писать документацию
🎯 Правила хорошего нейминга
Точность
Имя должно точно описывать сущность
Консистентность
Одинаковые паттерны для похожих вещей
Избегайте лишних слов
fileCount, а не numberOfFiles
Часть 4: Консистентность и очевидность (главы 17-21)
Консистентность
- •Naming conventions — единообразные имена
- •Coding style — форматирование, структура
- •Design patterns — типичные решения
- •Invariants — гарантированные свойства
Очевидность кода
Код очевиден, если читатель может быстро понять его без глубокого анализа.
✅ Хорошие имена и комментарии
✅ Консистентность
❌ Event-driven programming (сложно отследить)
❌ Generic containers (теряется семантика)
🚩 Red Flags — признаки плохого дизайна
Видео-серия Code of Architecture
Книга была разобрана в четырёх выпусках книжного клуба Code of Architecture с участием архитекторов Т-Банка:
Ключевые идеи
Complexity is incremental
Сложность накапливается постепенно, по капле
Working code isn't enough
Нужен хороший дизайн, не только работающий код
Deep modules
Много функциональности за простым интерфейсом
Information hiding
Инкапсуляция знаний о реализации
Pull complexity down
Сложность в реализации, простота в интерфейсе
Define errors out
Проектируйте API без ошибочных состояний
Comments as design tool
Пишите комментарии до кода
Consistency matters
Консистентность снижает cognitive load
Связанная книга
Software Architecture: The Hard Parts
Практические решения для декомпозиции и управления сложностью в распределённых системах.