Ментальные модели для программиста

Ментальная модель — упрощённое представление о том, как работает система; набор ментальных моделей позволяет разработчику быстро принимать решения, предсказывать поведение кода и выбирать правильные инструменты.

Зачем нужно

Опытный разработчик не просто знает синтаксис — он думает через ментальные модели: "первопричина vs симптом", "сложность vs гибкость", "сейчас vs потом". Эти модели ускоряют принятие решений, помогают debug-гировать и объяснять коллегам технические решения.

Где используется

Архитектурные решения — какой подход выбрать
Debug — поиск первопричины
Оценка задач — что может пойти не так
Коммуникация — объяснение технических решений бизнесу

Ключевые ментальные модели

Первопричина vs симптом (Root Cause Analysis)

Симптом: "Приложение тормозит"
Причина 1: Медленный SQL-запрос
Причина 2: Нет индекса на таблице
Первопричина: N+1 запросы в ORM

Инструмент: "5 почему"
Почему тормозит? → Много запросов к БД
Почему много запросов? → ORM делает запрос на каждый элемент
Почему каждый элемент? → Нет eager loading
→ Решение: добавить .include / JOIN

Инверсия (Inversion thinking)

Вместо "как сделать хороший код" →
спроси "что делает код плохим"

Вместо "как провести хорошее демо" →
спроси "что гарантированно провалит демо"

Применение:
"Что может сломать нашу авторизацию?"
→ Утечка JWT, replay attack, отсутствие expiry
→ Защита от этого — хорошая авторизация

80/20 (принцип Парето)

20% функциональности → 80% использования

Применение в разработке:
- 20% кода вызывается 80% времени → оптимизировать его
- 20% фич используется 80% пользователей → приоритет
- 20% усилий даёт 80% результата → фокус

Пример:
Оптимизировать холодный старт приложения (редко используется)
vs кеширование списка продуктов (каждый запрос) →
Парето говорит: список продуктов важнее

Сложность накапливается (Accumulating Complexity)

Каждое решение добавляет сложность к системе.
Сложность почти никогда не уменьшается сама.

Дёрево решений для любого изменения:
"Насколько это увеличит сложность системы?"
"Оправдана ли эта сложность ценностью?"

Принцип YAGNI (You Ain't Gonna Need It):
Не добавляй функциональность "на будущее"

Компромиссы (Trade-offs)

В разработке нет бесплатных решений:

Скорость vs Качество
  Быстрый деплой → больше технического долга

Гибкость vs Простота
  Generic решение → сложнее поддерживать

Согласованность vs Доступность (CAP теорема)
  Distributed systems не может иметь оба одновременно

Навык: явно называть trade-off при предложении решения:
"Если сделаем X, получим Y, но потеряем Z"

Модели абстракций

Leaky abstractions (Дырявые абстракции):
Все нетривиальные абстракции "протекают"
(закон Спольского)

Пример:
SQL ORM скрывает SQL, но N+1 проблема просочилась
HTTP-клиент скрывает сокеты, но timeout возникает

Вывод: понимай, что скрывает абстракция

Частые ошибки

Ошибка	Проблема	Решение
Лечить симптом, а не причину	Проблема возвращается	"5 почему" перед решением
Оптимизировать преждевременно	Трата времени на неважное	Pareto + профилирование первым
Не называть trade-offs явно	Коллеги принимают решение без полной картины	"Плюс X, минус Y" при каждом предложении
Добавлять функциональность "на вырост"	Неиспользуемый сложный код	YAGNI: только то, что нужно сейчас