Задача: Реализовать формы и актуальные публичные интеграции заново
Реализовать формы и актуальные публичные интеграции заново
Не переносить legacy-реализацию форм буквально, а заново реализовать только актуальные пользовательские сценарии на haih-cms.
Цель
Реализовать на новой платформе только те формы и публичные интеграционные сценарии, которые нужны новому сайту.
Что сделать
- По результатам инвентаризации определить реально нужные формы и пользовательские действия.
- Не переносить legacy-код форм, Devise/OAuth или другие интеграции автоматически только потому, что они существуют в старом проекте.
- Для каждого нужного сценария спроектировать новую реализацию средствами haih-cms и текущего стека.
- Настроить валидацию, сообщения об ошибках и подтверждение успешной отправки.
- Проверить защиту от очевидного спама и повторных отправок.
- Подключать внешние интеграции только при подтверждённой необходимости.
Результат
Новый сайт содержит актуальный набор форм и публичных интеграций без зависимости от legacy-кода.
Критерии готовности
- Все необходимые пользовательские сценарии реализованы.
- Неактуальные OAuth и прочие legacy-интеграции не переносятся автоматически.
- Формы работают независимо от Ruby-приложения.
- Чувствительные параметры не фиксируются в открытой задаче.
Ворклоги
Изменение подхода к формам и интеграциям
Legacy-реализация форм, OAuth и внешних интеграций не переносится автоматически. На новом сайте будут заново реализованы только фактически нужные пользовательские сценарии.
Это позволяет избавиться от зависимости от старых Rails-гемов и устаревших провайдеров и не переносить функциональность только ради совместимости.
Legacy-дефект: социальная авторизация в форме обратной связи не работает
В интерфейсе формы обратной связи пользователю предлагаются четыре варианта социальной авторизации:
- Google+ (
/auth/gplus) - ВКонтакте (
/auth/vkontakte) - Twitter (
/auth/twitter) - Facebook (
/auth/facebook)
Фактически ни один из этих сценариев сейчас не работает.
Почему это важно
Это ещё один показательный пример деградации legacy-функциональности: интерфейс продолжает обещать пользователю возможности, которые технически уже не существуют или не поддерживаются. Для посетителя это выглядит как поломка сайта, а для сопровождения создаёт ложный объём функциональности, который приходится отдельно исследовать.
Отдельно примечательно наличие Google+ — сервиса, давно закрытого для потребительского использования. Сам факт сохранения такого пункта в актуальном интерфейсе показывает, насколько легко внешние интеграции превращаются в технический долг, если их не пересматривать регулярно.
Вывод для новой версии
Социальную авторизацию нельзя переносить только потому, что она присутствует в старом интерфейсе. Для haih-cms нужно заново определить, нужна ли пользователю авторизация вообще, и если нужна — реализовать только актуальные и реально поддерживаемые сценарии.
Лучше иметь простой работающий путь обратной связи, чем набор визуально привлекательных, но неработающих способов входа.
Практический эффект для миграции
Legacy OAuth-маршруты следует рассматривать как исторический функционал, а не как обязательное требование к новой реализации. Их наличие нужно учитывать при инвентаризации, но не воспроизводить без подтверждённой пользовательской ценности.