Учёт занятий
для танцевальной студии

Один зал, три группы,
у каждой ученицы свой остаток

Задача звучала так. Студия с одним залом, три группы с фиксированными днями и временем, составы пересекаются. Абонемент на 1, 4 или 8 занятий, срок месяц, один перенос. Нужно знать, сколько занятий у человека осталось, и списывать их по факту явки.

Два условия задали всю конструкцию. Ученицы живут во ВКонтакте, поэтому своего сайта и личного кабинета в системе нет вовсе, это записано в техзадании с первого дня. А вся коммуникация студии на тот момент шла в общем чате ВК, сообщество для рассылок ещё даже не было оформлено.

Я разобрал правила с заказчицей, собрал учёт, проверил сценарии и передал ей код с инструкциями. Цель была дать владелице возможность самой вести расписание, абонементы и явку. Аренду зала просили сразу, но вторым этапом.

В рабочем сценарии владелица заводит ученицу и абонемент, получает список к занятию, отмечает пришедших и закрывает занятие. Система списывает посещения по отметкам. Ученица может получать опросы и уведомления в ВК, если сама написала сообществу.

К передаче владелица уже вела учёт в боте. Подключение учениц к ВК ещё не состоялось, поэтому опросы не уходили и явку она отмечала вручную. Изменение времени работы или финансовый эффект я не измерял.

Правила студии я не упрощал под удобство кода.

• Занятие списывается, когда владелица отметила человека на занятии. Ни "не приду", ни молчание, ни неявка списания не дают.
• Перенос добавляет к сроку семь дней, лимит один на абонемент.
• Срок идёт независимо от явки. В конце неиспользованные занятия сгорают, и ученице называют число сгоревших. По техзаданию это первый источник споров, и лучше сказать заранее.
• Остаток считается суммой по всем действующим абонементам, а не по последнему. Иначе у той, кто купила второй, не дождавшись конца первого, цифры разъехались бы на всех экранах.

Любое движение остатка или срока идёт записью в журнал - что изменилось, на сколько, из-за чего и кто это сделал. Девять причин, от выдачи и списания до ручной правки и аннулирования. Поправить остаток молча нельзя, даже у кнопки "+1 занятие" комментарий обязательный. Через месяц видно, почему у человека именно столько занятий.

Порядок работы заказчица задала сама, прямо в постановке. Сначала разобрать задание на дыры, потом писать код, и каждый законченный кусок проверять, прежде чем идти дальше. Я так и работал.

Со стороны студии это выглядит скучно, и в этом смысл. Данные при обновлении не теряются - всё, что учтено, лежит в базе, а у каждого исходящего сообщения свой ключ, поэтому повтор не рассылает дубли. А если занятие закрыли с ошибкой, сутки есть кнопка переоткрыть, и списания откатятся записями в журнале.

Техзадание прошло проверку до первой строки кода, по одним только файлам задания, без моих пояснений и доводов. Так находятся противоречия, которых автор уже не видит, потому что помнит, как задумано. Часть найденного меняла устройство базы - то есть всплыла бы только после первой миграции, и переделывать пришлось бы вместе с живыми данными студии.

Три примера, чтобы было видно, что это не формальность. Перенос начислял плюс неделю всем, кто нажал кнопку. При двух абонементах у человека оказывалось два переноса и плюс две недели к сроку. Занятие могло закрыться само с нулём отметок и запереться - тогда все, кто был на нём, отходили бы бесплатно, а посещаемость врала бы потом всегда.

Дальше проверки на боевой базе, после каждой выкатки, которая трогала учёт или очередь отправок. Не выборочно, а прогоном целиком - выдать абонемент, отметить явку, закрыть занятие, записать индив и аренду зала. Последний такой прогон был 4 сентября. Один дефект нашёлся только там, на живой базе, и ни одна проверка без базы его не видела.

1. 01

   Разбор задания до кода

   Задание проверяется на дыры отдельно от меня, по одним только файлам. Ни одного моего пояснения, иначе проверка начинает достраивать за автора вместо того, чтобы спрашивать.

2. 02

   Код блоками, проверка после каждого

   Требование заказчицы, и я держался его весь проект. Закончен блок кода - проверка, и только потом следующий блок.

3. 03

   Тесты и сверка схемы

   Тесты на каждый блок и свой скрипт, который сверяет миграции с моделями без живой базы. На рабочей машине нет ни Docker, ни Postgres, и расхождение иначе всплыло бы только на сервере.

4. 04

   Прогон на боевой базе

   После каждой выкатки, которая трогала учёт или очередь. Сценарий целиком, от выдачи абонемента до закрытия занятия, а не выборочные проверки.

4 сентября проект ушёл владелице. Отдавать надо было не только код. Дальше она собиралась вести бота со своим ИИ-агентом, а значит, агент должен разобраться в системе без меня.

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

Условие с моей стороны было одно. Чужого ИИ-агента на свой сервер я не пускаю, поэтому переезд на её собственный VPS - первый шаг, и инструкция написана под него. Старый сервер при этом гасится не сразу, а после того, как новый отработает день.

Для владельца бизнеса в такой истории это главное. Код, документы и порядок переезда у неё на руках, и дальше систему можно вести своими силами или чужими, не разбираясь в чужом коде с нуля.