Модуль 3 · Урок 8 · ~10 минут

Сначала модель данных

Одна идея этого урока: код меняется легко, схема данных – тяжело. Поэтому сеньор проектирует данные до кода.

Знакомая ситуация

Ты запустил курс, агент за вечер собрал приложение с доступами. Через полгода решаешь добавить потоки: один курс – несколько наборов с разными датами. Просишь агента – и он выдаёт: «В базе доступ записан как строка "курс + дата покупки". Потоков в модели нет. Придётся менять схему и аккуратно переносить записи всех живых учеников».

Поменять код агент может за минуты. А вот данные 800 учеников уже лежат в старой форме – и их так просто не перепишешь. Заметь: код – не проблема, проблема – форма, в которой накоплены данные.

Код – мягкая часть системы: агент перепишет его за минуты. Схема данных (data schema) – твёрдая: в ней уже накоплена история реальных людей и платежей. Поэтому сеньор сначала проектирует модель данных, потом код вокруг неё.

Сущности и связи – простыми словами

Модель данных (data model) отвечает на два вопроса. Первый: какие сущности (entities) есть в твоём мире – то есть какие «вещи» система различает и хранит. Второй: какие между ними связи (relations).

Для твоей школы это выглядит так:

1
Сущности entitiesУченик, курс, поток, платёж, доступ. Каждая – отдельная «карточка» со своими полями, а не строчка текста внутри другой.
2
Связи relationsУченик записан в поток. Поток принадлежит курсу. Платёж сделан учеником и открывает доступ. Доступ связывает ученика с потоком.
3
Вопросы к модели model questionsМожет ли ученик быть в двух потоках? Бывает ли доступ без платежа (подарок)? Что происходит с доступом при возврате денег? Ответы – это и есть проектирование.

Обрати внимание: в этих вопросах нет ни слова про код. Это вопросы про твой бизнес – и отвечать на них должен ты, а не агент. Агент лишь предложит варианты.

Линус Торвальдс, создатель Linux и Git, сформулировал это ещё в 2006 году в переписке о дизайне Git:

«Плохие программисты беспокоятся о коде. Хорошие программисты беспокоятся о структурах данных и связях между ними» (bad programmers worry about the code, good programmers worry about data structures and their relationships).

Он прямо говорил, что проектирует код вокруг данных, а не наоборот, – и называл это одной из причин успеха Git.

Почему миграция – одна из самых дорогих операций

Изменение схемы при живых пользователях называется миграцией данных (data migration). Это дорого по одной причине: старые данные уже существуют, и их нельзя «перегенерировать» – только аккуратно преобразовать, ничего не потеряв.

Пока ты переносишь записи, приложение продолжает работать: кто-то платит, кто-то заходит на урок. Ошибся – и у реального ученика пропал оплаченный доступ. Поэтому час, потраченный на модель данных до запуска, экономит недели миграций после. Это то же инвестиционное мышление из урока 1, только ставки выше: здесь ошибка бьёт не по коду, а по живым людям.

Как думают три уровня

Джун · данные как побочный эффектПросит агента «сделай курс с оплатой» – и данные складываются так, как агенту было удобно в моменте. Какая схема получилась, никто не смотрел. Узнают о ней при первой серьёзной доработке.
Мидл · схема под сегодняшний экранРисует модель данных заранее – но исходя из текущих экранов: «на странице курса нужны название и цена, значит, храним название и цену». Модель повторяет интерфейс, а не бизнес. Появился новый сценарий – схема снова не подходит.
Сеньор · модель под жизнь данных на годыПроектирует от бизнеса, а не от экрана: какие сущности есть в реальности, как они связаны, что из этого поменяется через год. Закладывает потоки, возвраты и подарочные доступы в модель до того, как они понадобились экранам.

Проверь себя

1. Ты начинаешь новое приложение для школы. Агент предлагает: «Начнём со страниц, а базу данных я сделаю по ходу». Что ответит сеньор?

2. В твоём приложении доступ ученика хранится как текст: «Курс ИИ, оплачен, март». Чем это обернётся?

3. Нужно добавить рассрочку: платёж больше не равен «оплатил один раз». Как подойдёт сеньор?

Что говорить агенту уже сегодня

Источники