Хорошие имена для вещей

Именование: основы объектно-ориентированного подхода

Именование: основы объектно-ориентированного подхода

Рассмотрим проектирование объектов/классов на примере…

Ситуация

Вы когда-нибудь проектировали модель данных (в коде, SQL или Excel-таблицах)? Знакомо ли вам следующее?

*** антипаттерн — не копируйте ***
* User
  - id
  - avatarUrl
  - name
  - email
  - password

* Agent
  - id
  - primaryPhoto
  - name
  - email
  - agentEmail
  - agentPhoneMain
  - agentEmailPrimary
  - agentPhonePrimary
  - agentAddressFull
  - agentCompanyName
  - agentCompanyAddress
  - *userEmail* - Указатель на таблицу User ^^^

Где ошибка?

Технически ошибки нет — просто данные нуждаются в реорганизации.

Знакомо ли вам следующее?

1. Любое изменение в вашем приложении потребует часов утомительной отладки.
2. Любые меняющиеся требования приведут к:

Почему так плохо называть поле agentEmailPrimary?

Для начала, вы не создаёте нечто совершенно новое во вселенной. Избыточная специфичность таит в себе несколько ловушек:

1. «Привязка» к крайне специфичному имени означает, что agentEmailPrimary, скорее всего, сделает ваши представления и связанный код на 0 % повторно используемыми, а также приведёт к назойливым повторяющимся багам:

• Данные не синхронизируются между таблицами (неочевидно, должно ли user.email распространяться на agent.agentEmail или наоборот — не говоря уже о сложности ручной реализации того, где и как enforcing эту «логику»…)
• Правила и логика валидации, вероятно, дублируются и становятся несогласованными.
• Ваш проект будет всё больше напоминать шаткую башню из Jenga.
• Хрупкость накапливается с каждым новым файлом, поскольку даже для тривиальных изменений требуется предельная внимательность к деталям.

1. agentEmailPrimary может означать несколько разных вещей. Избегайте двусмысленности с помощью более коротких имён.

• Остерегайтесь бессмысленных излишеств в формулировках. Primary? Это лишь порождает дополнительные вопросы: есть ли Secondary? Это для их основного ближайшего родственника?

Хватит слов, Дэн, как же это должно выглядеть?

Решение

// Консолидированная схема:

User
  - id
  - role: ['agent', 'lead', 'admin']
  - name
  - phone
  - address
  - email
  - password
  - company
    - name
    - address

Я удалил таблицу Agent, поскольку она не содержала полей, уникальных для агентов. А объект User.company (с .name, .address) появился, как только именование было приведено в порядок.

Некоторые руководящие принципы:

1. Устраняйте ненужные таблицы. Вам действительно нужна таблица statuses? Когда можно добавить поле status::VARCHAR(8) в таблицу User? Ладно, используйте лишние байты на строку.
2. Старайтесь объединять связанные таблицы. Данные
3. Удаляйте избыточные коллекции данных (например, уберите таблицу ActivityLogs, если её заменяет аналитическое решение.)
4. Старайтесь сохранять все имена полей в виде одного слова/существительного/местоимения. Вполне нормально полагаться на контекст, предоставляемый именем таблицы. (Например, PersonalAccount.email против BusinessAccount.email — контекст задаётся именем таблицы.)
5. Не существует таких вещей, как Agent.agentEmail или Agent.agentPhonePrimary. Точка. Повторите за мной: «это email и phone.»
6. Используя крайне специфичные имена, вы замуровываете в камне определённый уровень повторного использования кода и устойчивости, а именно НОЛЬ процентов.
7. Вы не оказываете себе услуг подобными штуками: User.profileSummaryEmail. 💞

Рекомендуемое чтение:

1. Возможно, нормализация — это не нормально
2. Торговля между нормализацией и денормализацией баз данных
3. http://phlonx.com/resources/nf3/
4. https://en.wikipedia.org/wiki/Database_normalization