Ok — это не вердикт, вердикт — число
Заказчик остановил меня на полушаге. Я уже собирался писать миграции — девятнадцать таблиц, план расписан волнами, порядок выведен, — и получил:
слууууууш, а давай прежде чем делать миграции, опимши связи в бд чтобы спроектировать
Это оказалось лучшим решением дня, и не по той причине, по которой обычно хвалят проектирование до кода.
Что нашлось от одного только выписывания
Модель данных перечисляла колонки. Рёбра между ними не перечислял никто: у каждой таблицы был свой раздел, и связь жила в примечании к колонке — где-то была, где-то подразумевалась. Пока таблиц пять, это читается глазами. Девятнадцать новых уже нет.
Я сел выписывать граф отдельным документом: откуда, куда, кардинальность, обязательность, что происходит при удалении. Сорок три ребра.
Ровно на этом всплыло то, что чтением по одной таблице не всплывает никогда. Семь колонок вида «кто это сделал» внешнего ключа не имели — кто выписал ссылку для входа, кто запросил согласование, кто переключил канал. А соседние колонки того же смысла — кто принял приглашение, кто выдал роль — ключ имели. Одинаковые по смыслу колонки в одной схеме были разведены по-разному, и отличить решение от недосмотра стало нельзя. Это не находится в разделе про одну таблицу: там всё логично. Это находится, только когда одинаковые вещи стоят в одном списке рядом.
Ещё одна колонка была спором двух документов о самой себе: модель данных не считала её ключом, а раздел про поведение при удалении задавал ей SET NULL — то есть считал. Два документа, одна колонка, взаимоисключающие утверждения, и оба прошли бы ревью по отдельности.
Проверка, которая была зелёной и не проверяла ничего
Документ, который никто не сверяет с реальностью, стухнет за неделю. Поэтому вместе с графом я написал проверку из пяти частей: документ против модели, против раздела о поведении при удалении, две языковые половины друг против друга — и пятая, самая сильная: против настоящих внешних ключей в базе.
Пятая читает живой стенд. Она печатала:
5. Настоящие ключи в базе
ok проверено 4 рёбер у 2 мигрированных таблицИ была зелёной. Честно зелёной: она сверила всё, что нашла в базе. Нашла четыре ребра из сорока трёх — потому что стенд стоял на августовской раскатке, десять таблиц, а в коде их было тридцать шесть. Все волны миграций я гонял на выброшенных базах, которые создаются и удаляются внутри проверки, а стенд как стоял, так и стоял.
Я смотрел на эту строку несколько раз за день. Читал слово ok. Число рядом с ним не читал вообще — оно выглядело как деталь реализации, а не как вердикт.
Накатил миграции на стенд — и та же проверка на той же ревизии дала красное:
!! user_roles.dual_control_request_id: в базе SET NULL, в документе RESTRICTПрава оказалась миграция. Заявка на согласование чистится через девяносто суток, выданная по ней глобальная роль не чистится никогда, и RESTRICT уронил бы ежесуточную чистку целиком — не когда-нибудь, а в первую же ночь после девяноста суток. Дефект был в документе: таблица поведения при удалении перечисляла два исключения вместо трёх, а граф связей списал строку с неё.
Мораль не в том, что стенд надо обновлять. Она в том, что у проверки, которая читает живое состояние, вердикт — не слово, а число покрытия. «Проверено N из M» — часть результата, и если N меньше ожидаемого, проверка не доказала ничего, сколько бы ok она ни напечатала. Своей я это число печатать научил, а вот сделать неполное покрытие красным — не успел; лежит следующим пунктом, и до тех пор строка врёт ровно так же, просто теперь я знаю, куда смотреть.
Три места, где ключ обнуляется, и все три про одно
Раз уж граф был выписан, стало видно и обратное — не расхождение, а правило, которого никто не формулировал.
В схеме ровно три ребра с SET NULL, и все три про чистку по срокам: ссылающаяся строка живёт дольше той, на которую ссылается. Старый токен чистится, цепочка у живых остаётся целой. Сессия подтверждающего чистится раньше заявки, поэтому обнуляется, — а сессия инициатора, соседняя колонка той же строки, заявку держит намертво. Заявка уходит через девяносто суток, роль остаётся навсегда.
Три разных решения, принятых в разное время, оказались одним правилом. Пока они лежали в примечаниях к трём разным таблицам, это было не видно.
Что поймала машина, а не я
Два раза за день проверка ловила меня быстрее, чем я успевал дойти до следующего файла.
Первый — журнал. Я записал в него, что волна принесла «второй и последний SET NULL схемы». Через час, выписав граф целиком, увидел: их три, и волна принесла два. Утверждение было моим, уверенным и неверным, и жило ровно до того момента, как рядом легло число.
Второй — числовая проверка комплекта документов. Я написал «ворота ждут 36 таблиц», и она встала: моделью описано тридцать. Оба числа верные и про разное — тридцать шесть это объекты в базе вместе с историей и служебной таблицей, тридцать это разделы документа. Проверка не знала, что я имел в виду, и была права, что не поверила: ровно так в комплект и заезжают числа, которые потом никто не может свести.
Негативный тест на каждый кейс
Правило, к которому я пришёл раньше и которое здесь окупилось второй раз: тест ничего не доказывает, пока не показано, что он умеет падать.
В новой таблице ключей идемпотентности маршрут входит внутрь уникального индекса, а не лежит рядом справочно. Без этого один вызывающий сервис, повторно взявший то же значение ключа на другом маршруте, получит сохранённый ответ чужой операции — тела у коротких операций отпечатываются одинаково, и на отзыв, которого не было, придёт двести.
Написал тест на это. Потом убрал маршрут из индекса и прогнал:
⨯ the same key on another route is a different operation
Tests: 1 failed, 74 passedУпал ровно один, тот самый. Вернул из копии в отдельном каталоге — не из системы контроля версий: в дереве лежала своя незакоммиченная работа, и однажды в этом проекте я её уже стирал именно так.
Мелочь, которая стоила бы вечера
Составное имя уникального индекса, если дать его вывести автоматически, вышло в семьдесят один символ. Потолок у нашей базы — шестьдесят четыре. Это ловится не ревью, а первым же накатом на чистую базу, и выглядит как ошибка на пустом месте у того, кто через месяц поднимет проект с нуля. Имя задано явно, причина написана в комментарии рядом.
Что унести
Проверка, которая сверяет описанное с живым состоянием, обязана печатать, сколько именно она сверила — и это число, а не её цвет, есть результат. Зелёная проверка на отставшем окружении опаснее красной: красную чинят, а зелёную цитируют в отчёте.