NovОдин факт не должен жить в пяти разных местах
Почему Александр Ельшин старается не хранить цену, статус или срок как независимые копии на разных страницах сайта.
Материал отражает практическую позицию указанного эксперта. Как готовятся и проверяются публикации — в редакционной политике NovAsia.
У большого сайта есть неприятная особенность: одна и та же цифра быстро размножается.
Цена появляется в карточке проекта, на самой странице, в сравнении, калькуляторе, подборке и английской версии. Пока данных мало, это почти незаметно: человек меняет значение вручную в двух-трёх местах и считает задачу закрытой. Проблема начинается позже, когда интерфейсов становится больше, а каждое из этих мест начинает жить по своим правилам.
Именно поэтому каталог проектов и профили застройщиков должны получать общие данные из одного источника, а не поддерживать независимые копии цены и статуса.
Один источник должен быть определён для каждого факта
Фраза «единый источник данных» полезна только тогда, когда понятно, что именно считается исходным значением. Цена может приходить из реестра проекта, статус — из редакционного поля, район — из отдельного справочника, а расчётная стоимость за квадратный метр вообще не должна храниться вручную, если её можно получить из цены и площади.
Я стараюсь разделять исходные факты и производные значения. Если площадь изменилась, зависимый расчёт должен пересчитаться сам. Если изменился статус продаж, карточка, сравнение и связанные блоки должны прочитать одно и то же состояние. Чем меньше ручных копий, тем меньше мест, где старое значение может пережить обновление.
При этом централизация не означает, что всему сайту нужен один огромный файл. Важнее другое: у конкретного факта должен быть понятный владелец, а остальные части системы не должны тихо создавать собственные версии этого факта.
Ручное исключение быстро становится второй базой данных
Самый опасный сценарий начинается с безобидной просьбы: «Давайте здесь временно покажем другую цену». Если интерфейс получает возможность переопределять исходное значение без явного правила, через несколько месяцев уже никто не помнит, почему одна карточка отличается от остальных.
Иногда исключение действительно нужно. Например, конкретный блок может показывать цену «от», диапазон или значение с отдельной датой проверки. Тогда это должно быть отдельным смысловым полем, а не скрытой подменой общей цены.
Мне важно, чтобы различие можно было объяснить по данным. Если две страницы показывают разные числа, система должна позволять понять, откуда взялось каждое из них, а не оставлять разработчика искать причину по шаблонам и вручную внесённым строкам.
Централизация не проверяет правду
Техническая система не знает, правильная ли цена пришла от редакции или застройщика. Она решает другую задачу: не дать одной подтверждённой цифре превратиться в пять разных после публикации.
То же относится к статусу продаж, дате проверки, условиям программы, району и другим полям, которые человек видит в нескольких местах. Ошибочный исходный факт тоже разойдётся последовательно — поэтому редакционная проверка и техническая целостность нужны одновременно, но отвечают за разные виды ошибок.
После изменения важного поля я хочу увидеть не только правильную основную страницу. Полезная проверка проходит по всем местам, где факт повторяется: каталогу, карточке, сравнению, связанным блокам и другой языковой версии, если она использует тот же источник.
Для меня хороший релиз — это когда обновление одного факта предсказуемо расходится по всем нужным интерфейсам и не создаёт новую версию реальности на каждой странице.