Третья hard problem: почему инженеры спорят о папках

Знаете классический анекдот? В Computer Science есть только две по-настоящему сложные задачи: придумать название и инвалидация кэша. Шутка, но с двойным дном: обе проблемы на самом деле упираются в понимание контекста, а не в алгоритмы.

Третья проблема, о которой никто не говорит

Автор статьи на mmapped.blog называет её tree mapping — попыткой отобразить произвольный граф связей на иерархическую структуру. То есть впихнуть паутину в дерево.

В реальности идеи, зависимости и связи — это паутина. Но человеческий мозг любит иерархии: категории, папки, ветки, уровни. Проблема в том, что не всё укладывается в одну структуру.

Где это всплывает

Файловые системы

Вспомните, как вы сохраняете счёт от стоматолога. В архив? В медицину? В налоги 2024? А может, в три места сразу? Это реальный design problem, который операционные системы решают уже полвека.

Windows и macOS исторически группировали файлы по приложениям, Linux — по типам. Оба подхода ломаются на сложных сценариях.

ОРГАНИЗАЦИЯ КОДА: ДВА ПОДХОДА
──────────────────────────────
По компонентам          По языку
┌─────────────────┐     ┌─────────────────┐
│ /payments       │     │ /ts              │
│  ├─ index.ts    │     │  ├─ payments.ts  │
│  └─ main.rs     │     │  └─ users.ts     │
│ /users          │     │ /rs              │
│  ├─ index.ts    │     │  ├─ payments.rs  │
│  └─ main.rs     │     │  └─ users.rs     │
└─────────────────┘     └─────────────────┘
         ▲                      ▲
    Людям удобно          Инструментам удобно

Google, кстати, организовал репозитории по проектам, а затем написал Bazel — инструмент сборки, который не привязан к языку.

Письмо и документация

Цель писателя — закодировать паутину идей в строку слов, используя дерево фраз. Книги и статьи линейны, а мысли внутри — нет.

Попробуйте объяснить математический концепт линейно или написать документацию, где каждый разработчик найдёт ответ, не перечитывая всё. Обычно это превращается в борьбу с tree mapping.

Архитектура городов

В 1965 году архитектор Кристофер Александер выпустил эссе A City is Not a Tree. Его тезис: искусственные города проектируют как деревья, а живые города — как сеть пересечений и переходов.

ДВА ТИПА ГОРОДОВ
────────────────
Дерево (искусственный)    Полурешётка (живой)
┌───────────────────┐     ┌───────────────────┐
│  Жильё            │     │    Жильё ─── Работа
│    │              │     │       │     ╱      │
│  Школа            │     │    Кафе ─── Парк   │
│    │              │     │       ╲    │       │
│  Магазин          │     │      Магазин ────  │
│                   │     │         │          │
│  (изоляция)       │     │  (пересечения)     │
└───────────────────┘     └───────────────────┘

Почему это важно знать

Многие командные споры — это не технические споры, а споры о том, как мыслить о задаче.

Микросервисы или монолит? На деле это вопрос о том, какие связи важны. Как назвать сервис? Это вопрос о его месте в иерархии. Почему документация непонятная? Потому что паутину понятий попытались запихнуть в линейный текст.

Выводы

• Если вы спорите о классификации, а не о логике, вероятно, перед вами tree mapping.
• Идеальной иерархии может не существовать.
• Нужно осознанно выбирать компромисс: удобство людей или удобство инструментов.

Следующий раз, когда задача кажется «необычно сложной», проверьте: а не пытаетесь ли вы отобразить граф на дерево?

Ссылки

• The Third Hard Problem — оригинальная статья
• A City is Not a Tree — эссе Кристофера Александера (1965)