Устойчивый сайт — это не просто сайт, который рассказывает об устойчивости. Он должен быть и технически построен так, чтобы его можно было долго сопровождать, расширять и проверять. Именно над этим мы и продолжили работать.
В центре внимания был один принцип: Single Source of Truth, коротко SSOT. У каждой важной информации должен быть ровно один надёжный источник. Цвета, индикаторы статусов, данные организации, тексты, структуры базы данных и процессы контроля качества не должны копироваться во множестве мест с небольшими различиями. Иначе каждое изменение становится более рискованным, медленным и дорогим.
Что мы улучшили
Мы добавили новые проверки соответствия, которые автоматически контролируют соблюдение ключевых правил. Среди них — SSOT-аудит и i18n-аудит для переводов. Проверка SSOT теперь, помимо прочего, не позволяет создавать таблицы базы данных в API-маршрутах или вновь появляться старым шаблонам hardcoded-content.
Также ужесточён процесс выпуска. Вместо того чтобы игнорировать предупреждения или проверять их лишь после сборки, путь контроля качества теперь выстроен чётче: TypeScript, линтинг, соответствие, тесты и production-сборка. Это делает ошибки заметными раньше и укрепляет надёжность перед релизами.
В дизайн-системе несколько жёстко заданных цветов были перенесены в централизованные UI-конфигурации. Собственные цвета приложения для Open-Graph-изображений, оверлеев обратной связи, страниц ошибок, форм категорий, фактических листов, узоров hero-блоков и профилей клиентов теперь находятся в именованных местах. Это уменьшает скрытые зависимости и делает будущие правки более целенаправленными.
Ещё одним пунктом стало разделение содержимого и конфигурации. Значок услуги вроде «Скоро» не должен жёстко находиться в технической конфигурации услуги, а в переводах. Такие небольшие переносы в долгосрочной перспективе сильно повышают удобство сопровождения.
Почему это важно
Хардкодинг часто удобен, но порождает долг. Цвет здесь, немецкий текст там, класс статуса в файле домена, SQL-выражение в API-маршруте: каждое отдельное место выглядит безобидно. Вместе же они приводят к системе, которую трудно понять и трудно безопасно изменять.
Поэтому SSOT — не самоцель. Он помогает нам работать быстрее и точнее:
- Изменения происходят в одном месте, а не во многих.
- Дизайн-решения остаются согласованными.
- Переводы становятся измеримыми.
- Структура базы данных остаётся в миграциях и файлах схемы.
- Ревью могут сосредоточиться на поведении, а не на поисковой работе.
Что ещё предстоит
Направление ясно, но работа не завершена. Следующим шагом мы хотим сократить имеющийся долг по переводам. Новая i18n-проверка уже предотвращает появление новых отсутствующих ключей, но некоторые существующие пробелы всё ещё задокументированы как baseline.
Кроме того, конфигурации домена следует и дальше отделять от UI-текстов. Значения статусов вроде active, sold или reserved — это данные домена. Немецкие метки и визуальное представление должны корректно приходить через переводы и UI-маппинг.
Дизайн-система тоже заслуживает более глубокой консолидации. Хорошие централизованные строительные блоки уже есть, но некоторые старые слои токенов пересекаются. Цель — чёткая архитектура: примитивные токены, семантические токены, варианты компонентов и специфичные для областей маппинги.
Наш стандарт
Удобство сопровождения для нас — признак качества. Оно определяет, будет ли платформа работать только сегодня или её можно будет безопасно развивать и через год.
SSOT, разделение ответственности и DRY-код для этого не абстрактные понятия. Это конкретные рабочие правила: меньше копий, более чёткие границы, лучшая автоматизация и система, которая не делает изменения излишне трудными.
Именно над этим мы и продолжаем работать.