Недавно я наткнулся на API, который выявил разумное, но неудачное дизайнерское решение, специфика которого не имеет значения, если не считать того факта, что данные, о которых идет речь, в той или иной форме касались людей. Это хорошо описывается в следующем упрощении:

{
  employees: [
    {
      name: 'John Doe',
      email: '[email protected]',
      male: true
    },
    {
      name: 'Jane Doe',
      email: '[email protected]',
      male: false
    },
    {
      name: 'Joshua Doe',
      email: '[email protected]',
      male: true
    }
  ]
}

Ошибка здесь в том, что выше используется «мужской: истина» и «мужской: ложь», чтобы различать пол. Хотя это выглядит достаточно невинно, при дальнейшем рассмотрении его можно признать политически некорректным и граничащим с сексизмом. Эта деталь может показаться несущественной, но она раскрывает проблемную тонкость, о которой нам следует знать.

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

Быть мужчиной не по умолчанию

Даже если это было приемлемым, зачем использовать «мужской: правда», а не «женский: правда»? Это делает мужчин подразумеваемым по умолчанию, а женщин «не мужчинами». Представьте код, использующий эту информацию, следующим образом:

if (male) {
  // do one thing
} else {
  // do another thing
}

Опущенное условие ветви «еще» читается не как «если женщина», а как «если не мужчина», что является тонкой, но неоспоримой разницей.

Использование «female: true» вместо «male: true» не улучшит ситуацию. При стремлении к гендерному равенству нельзя рассматривать один пол как «более верный», чем другой, независимо от того, какой из них отдается предпочтение.

Пол — это не «или-или».

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

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

Люди должны были заметить

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

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

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

Это признак мужской среды.

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

Если вы хотите нанять сотрудников всех полов, очевидно, что предпочтение одного пола может убедить некоторых не обращаться в вашу компанию, независимо от их собственного пола. Это не означает, что «женщины не захотят у вас работать», поскольку мужчины точно так же знают об этом тоне и могут счесть его враждебным и решить поискать в другом месте.

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

Как сделать это правильно

Одним из способов улучшения этого API было бы одновременное наличие атрибутов «isMale» и «isFemale», чтобы поставить их в равное положение. Это позволило бы людям идентифицировать себя ни с одним, ни с одним, ни с обоими из них, что по-прежнему не охватывает весь спектр пола, который мы хотели бы включить.

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

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

Вам нужно знать пол человека или вы хотите это знать? Если вы используете эту информацию только для переключения между «Уважаемый мистер Доу» и «Уважаемая миссис Доу» в электронных письмах, которые вы отправляете, действительно ли это критически важная для бизнеса функция, которая вам абсолютно необходима? Скорее всего, вашему продукту вовсе не обязательно показывать точное местоимение, и вы создаете эту проблему искусственно.

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

Вывод

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

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

Есть чему поучиться

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

Первоначально опубликовано на https://islovely.co 3 мая 2016 г.