Пробую новую рубрику – разбор реальных рабочих задач. Если интересно и хотите видеть другие задачи, поддержите и поставьте 🔥
Разбираем задачу, которая часто встречается в мобильных приложениях (и я тоже ее делал)
Постановка задачи 💡
Как пользователь, я хочу управлять настройками пуш-уведомлений, чтобы отключить/включить определенные уведомления
С чего начать? 💬
С чего начинается танец СА? Правильно – с вопросов:
🤍 Какие группы уведомлений будут? (новости, акции)
🤍 Какие уведомления входят в каждую группу?
🤍 Планируются ли добавлять новые группы и уведомления в будущем?
🤍 Как настройки заданы по умолчанию?
🤍 Синхронизировать настройки между устройствами?
🤍 Нужна ли кнопка «Включить/выключить ВСЕ»?
🤍 Где в приложении размещаем экран настроек?
В итоге получаем инфу для БД, API и дизайна
Прописываем сценарии ✍️
Дальше подумаем над возможными сценариями:
🤍 Система задает дефолтные настройки для нового пользователя
🤍 Пользователь получает свои настройки
🤍 Пользователь меняет одну настройку
🤍 Пользователь меняет все настройки разом
Получилось не так уж и много
Проектируем БД ✍️
Возьмем самый сложный вариант – групп много, добавляться в будущем будут, настройки должны синхронизироваться
🤍 notification_settings – основная таблица (user_id, notification_id, is_enabled)
🤍 notification_groups – справочник групп
🤍 notification_types – типы уведомлений и их привязка к группам
Так мы сможем легко добавлять новые уведомления и группы
Проектируем API-запросы ✍️
Прикинем, какие API-запросы между фронтом и бэком понадобятся
🤍 GET /setting/notifications – получить настройки
🤍 POST /setting/notification или PUT /setting/notification/{id} – изменить настройку
🤍 POST /setting/notification/all – включение/выключение всех настроек
🤍 POST /setting/notification/default – внутренний метод для установки настроек по умолчанию
А теперь – неочевидные моменты ⚠
🤍 Дефолтные настройки. Вместо синхронного API-запроса лучше использовать асинхронное сообщение в брокер (например, Kafka). Потому что API-запрос может не отработать, и нужно думать, что с этим делать – ибо пользователь словит ошибку из-за отсутствия данных
🤍 Реакция UI. Запрос может отрабатывать долго и не отработать в итоге, и что в это время происходит на экране? Пользователь блокируется лоадером? Это кажется избыточным для такого простого действия
Лучше сделать искусственное обновление (Optimistic Update), когда пользователь нажмет тогл, то фронт сразу обновит его состояние и фоном отправит запрос. Если ошибка, фронт вернет предыдущее состояние и отобразит ошибку, а если все окей – ничего не поменяется
—————
⬇ Сталкивались с такой задачей? Пишите в комментах, как решали
#разбор_задач_системный_анализ