Плохой дизайн редко выглядит как одна большая катастрофа. Обычно он ощущается как постоянная усталость от системы: непонятно, где менять код, интерфейсы кажутся тяжелыми, а любая простая задача тянет слишком много контекста. Эта глава как раз про борьбу с такой сложностью.
Особенно ценно здесь то, как книга переопределяет хороший дизайн через управление сложностью: deep modules, information hiding, red flags и снижение когнитивной нагрузки. Такой взгляд помогает проектировать интерфейсы и границы так, чтобы системе было проще жить и меняться.
Внутреннюю архитектуру сервиса по этой главе обсуждать заметно легче: она дает сильный язык для разговора о качестве модулей, удачных границах и тех интерфейсах, которые либо скрывают сложность, либо размазывают ее по всей системе.
Практическая польза главы
Управление сложностью
Фокусирует на главной цели дизайна: снижать случайную сложность и повышать понятность системы.
Глубокие модули
Помогает проектировать интерфейсы, скрывающие внутреннюю сложность и уменьшающие cognitive load.
Design debt
Учит замечать ранние сигналы деградации дизайна и вовремя делать структурные улучшения.
Interview articulation
На интервью дает сильный язык для обоснования модульных границ и качества API-контрактов.
Источник
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
Связанные главы
- Что такое архитектура ПО и зачем она в System Design - даёт системный архитектурный контекст, в котором идеи Ousterhout про контроль сложности применяются не только в коде, но и в дизайне сервисов.
- Fundamentals of Software Architecture (short summary) - дополняет тему через архитектурные характеристики и trade-offs, которые помогают измерять цену сложности в реальных системах.
- Clean Architecture (short summary) - показывает, как снижать связность и проектировать границы модулей, чтобы complexity оставалась локальной.
- Software Architecture: The Hard Parts (short summary) - переводит принципы простоты в distributed-контекст, где решения по данным и интеграции быстро накапливают сложность.
- Tidy First? (Чистый дизайн) (short summary) - добавляет практику маленьких структурных улучшений, которая помогает постепенно убирать technical debt без больших рефакторингов.