Написан пост по итогам прохождения материала и занятий моделированием в текущем разделе курса. В посте приведены форматы (заголовки всей таблицы, заголовки колонок, содержание таблички необязательно) трёх табличек, которые вы разработали для вашего рабочего проекта сами (не надо копировать в пост таблички, которые вы взяли без изменений в материалах нашего курса).
Вернулась старая проблема. Опять. Второй или третий раз. Всему виной фрагментарное мышление. Перечитала обсуждения в эпике, и мои комменты там есть. И вроде даже направление было правильное. Но по итогу сделали заплатку, а не решение проблемы. Я описания внутри задач на разработчиков прочитала и сейчас сразу вижу, что это не будет работать. Точнее как, оно будет работать в каком-то проценте случаев. Но точно не всегда и даже сложно прикинуть этот процент больше 10% или 50%. Но задачи протестированы и закрыты. Попробуем подойти к проблеме системно.
У нас есть Журнал мероприятий. Там многостраничный список мероприятий с поиском и сортировкой. Начальное инженерное решение удовлетворило одну характеристику (гибкость конфигурации мероприятия) и со временем завалило другую (скорость поиска и сортировки по реквизитам). Конструктив инженерного решения - хранить все реквизиты мероприятия в колонке с типом jsonb.
Не зря ругают инженеров за мышление конструктивами. Первая мысль, которая у меня возникла - надо придумать какое-то другое решение. Прям с ходу “как переделать”. Останавливаемся. И возвращаем себя к мышлению о функциональности. Нужна концепция использования. Концепция системы ждёт своей очереди.
Опять же неприятно признавать, но ничего не поделаешь. Работает “испорченный телефон”. Чтобы его обойти, думаю первую табличку.
| № | Интересант | Сценарий использования |
|---|---|---|
| 1 | бухгалтер | … |
| 2 | техподдержка | |
| 3 | менеджер продукта | |
| 4 | БА |
Перемешались внешние проектные роли и внутренние. Но я думаю это правильный ход. Операторы работают с системой, но внутренние роли тоже работают, когда проверяют или когда разбирают проблемы. И может оказаться, что у них разные потребности.
Дальше преждевременно надеваю шляпу архитектора. У нас конфликт предпочтений будет сто процентов. Потому что он как минимум уже есть.
| № | роль | интерес/характеристика | предпочтение | обоснование |
|---|---|---|---|---|
| 1 | инженер платформы | нагрузка на БД | низкая/умеренная | если нагрузка под планочку, и ваш журнал не будет работать и всё остальное |
| 2 | аналитик | простота (внесения изменений) и гибкость конфигурации мероприятий | максимальная | можно настраивать без разработчиков |
| 3 | dba | оптимальность способа хранения данных | высокая | структура данных подобрана с учётом типов операций с этими данными |
| 4 | оператор | скорость поиска мероприятий | высокая | ? |
| 5 | разработчик | сложность внесения изменений в конфигурацию | умеренная | это только на скорость выполнения таких задач влияет |
| № | характеристика | время |
|---|---|---|
| 1 | нагрузка на БД | ops time |
| 2 | настройка конфигурации | dev time |
| 3 | структура данных | dev и ops |
| 4 | скорость поиска | ops time |
Я сейчас подумала, что при выборе подходяшек возможно ops time характеристики приоритетнее, чем dev time. Есть ещё такая штука как тренд. Что будет со временем происходить. А будет происходить две вещи: данных будет становиться больше, а скорость поиска будут хотеть сохранять быстрой. Это не совсем характеристика. Но это наводит на дополнительные размышления - а нужны ли мероприятия в журнале с начала времён?