in

Советы по написанию поддерживаемого кода: Модель данных.

В программировании большая часть проблем связана с организацией данных в структуре, которая имеет смысл и которая помогает решать проблемы и облегчает понимание кода. В этой статье я покажу вам, какие инструменты есть в вашем распоряжении и как ими пользоваться.

Строительные блоки

Чтобы упростить наше обсуждение, давайте сосредоточимся на том, что у нас есть в JSON — формате данных, который был создан на основе того, как данные могут быть жестко закодированы в JavaScript. Таким образом, нам не нужно думать о влиянии различных структур данных на производительность — мы фокусируемся только на полезности модели данных.

Примитивные значения

Это самые основные типы значений, которые мы можем иметь в нашей программе. В JSON эти значения являются:

  • логическое значение — значение true или false,
  • число — значение с плавающей запятой,
  • строка — последовательность букв и
  • null— отсутствует значение, которое все еще полезно для выражения определенных состояний.

С этими базовыми типами у нас уже есть возможность решать одно и то же по-разному. Например, для типа customer вы могли бы использовать некоторые из следующих:

  1. const customerType = “retail”;—который может принимать любое другое строковое значение, как действительное, так и недопустимое
  2. const isRetail = true;—более жесткий подход: два его варианта очевидны, но он не может предоставить больше возможностей
  3. const customerType = 2—может быть расширен, но требует документации для понимания значения каждого числа

Все, что вы решите, повлияет на то, насколько легко будет изменить код позже. При выборе типа значения для вашей переменной рекомендуется подумать о возможных изменениях и выбрать тип, который хорошо подходит как для текущих, так и для будущих потребностей.

Массивы

Массивы представляют собой упорядоченные списки значений. Массивы JavaScript могут смешивать значения любого типа, например:

const someArray = [ 1, 2, “test”, [“another”, “array]];

Хотя это допустимый массив, работа с массивами смешанных типов сбивает с толку. Намного проще придерживаться сохранения одних и тех же типов значений в массиве.

Важной особенностью массивов является то, что они упорядочены. Это делает их отличным выбором для мест, где вам важны похожие точки данных и где порядок имеет смысл. Например:

  • Товары в корзине — вы определенно хотите отображать товары из корзины в том же порядке и
  • учащиеся в классе — у каждого из них есть свой номер в списке.

Массивы хорошо работают, когда вы получаете доступ ко многим значениям последовательно. Это менее полезно, когда вы хотите определить, находится ли данное значение в массиве. Когда я ловлю себя на том, что часто использую includes(), чтобы посмотреть, есть ли в массиве какой-то объект, который я ищу, я воспринимаю это как потенциальный признак того, что мне следует реорганизовать структуру данных.

Объекты

Объект представляет собой структуру, состоящую из набора пар ключ–значение. Структура неупорядоченная, что делает ее подходящим выбором для многих мест, которые не вписываются в массив. Каждое значение объекта может быть понято независимо от всех остальных, поэтому вы можете без беспокойства смешивать различные типы значений. Пример объекта:

const user = {
  login: “lorem.ipsum”,
  email: “sin@dolor.com”,
  age: 24,
}

Объекты хорошо подходят для наборов именованных неупорядоченных свойств. Например, набор разрешений:

const hasAccessTo = {
  blog: true,
  blogAdmin: true,
  userAdmin: false
}

Встроенные объекты

JavaScript предоставляет множество типов объектов, которые вы можете использовать на стороне кода, чтобы сохранить ваши значения в более подходящей форме — и с методами, которые делают их более удобными для использования. Например:

  • Date—для значений даты и времени,
  • Set—для неупорядоченных наборов неназванных значений, которые не повторяются и
  • Symbol—нестроковый идентификатор, который не будет конфликтовать с другими значениями.

Эти типы очень полезны, но при передаче данных через веб-API, использующий JSON для представления данных, все они будут сериализованы в типы значений, описанные выше. В моей повседневной работе, где я программирую бизнес-приложения, единственные типы, которые я регулярно использую, – это даты.

Выберите подходящую структуру

То, как мы организуем данные, влияет на то, что может быть легко сделано в нашем коде. Давайте взглянем на приведенный выше пример разрешения:

const hasAccessTo = {
  blog: true,
  …
}

Это значение можно легко использовать в условных случаях, таких как: if (hasAccessTo.blog).

То же требование к списку разрешений может быть выполнено с помощью другой структуры данных:

const permissions: [{
    resource: “blog”,
    access: true,
  },{
    resource: “blogAdmin”,
    access: true,
  },{
    resource: “userAdmin”,
    access: false,
  },
]

То же условие, что указано выше, необходимо будет заменить на:

const blogPermission = permissions.find(x => x.resource === ”blog”);

if (blogPermissions?.value) {
…

Это гораздо сложнее прочитать, и проще написать код, который в некоторых конкретных случаях будет выдавать ошибки. Используя массивы, единственное, что мы “получаем”, – это порядок разрешений, который не должен иметь значения.

Создайте черновик

При организации данных в нашей кодовой базе необходимо учитывать множество факторов, и вызовы могут довольно быстро усложниться. Чтобы избежать переписывания кода, имеет смысл создать некоторую форму черновика для структур. В моем случае я часто описываю их именами, которые планирую использовать в тикетах, над которыми собираюсь работать. Часто, когда вы видите записанный дизайн вашей структуры, вы замечаете некоторые проблемы с ним.

Продолжайте совершенствоваться

Структура данных для вашего кода никогда не будет закончена — она должна постоянно развиваться вместе с вашим приложением. Изменение имен, после их появления во многих местах кода и в базах данных, будет болезненным. Однако это необходимо, потому что в противном случае несоответствие между именами и их текущим пониманием будет только возрастать по мере изменения ситуации с течением времени. Это распространенный источник задолженности по коду, которая часто медленно накапливается, пока не превращает работу с кодом в неприятное и непродуктивное занятие.

Автор истории Марчин Восинек @marcinwosinek.

What do you think?

Начинающий

Written by Drimprog

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

GIPHY App Key not set. Please check settings