Почему мы используем неописательные внутренние кодовые имена? [закрыто]

Я думаю, что использование кодовых имен довольно широко распространено. Наша компания тоже их использует.

Но моя главная проблема в том, что эти имена обычно нигде не документированы. И значение распространяется по устной речи. И имена не имеют ничего общего с функцией инструмента или объекта, который он назвал.

Я вижу шаблон, по которому внутренние тестовые машины названы в честь созвездий, а открытые серверы - в честь греческих богов. И проекты названы в честь мест или имени какой-то случайно выбранной кинозвезды или имени персонажа. Но нет никакой информации, доступной непосредственно от имени, являются ли машины Windows или Linux; 32 или 64 битные серверы. Или о чем проект.

У меня просто плохое предчувствие, когда я вижу сообщение коммита VCS о том, что кто-то только что разветвил проект «Gandalf» или «Callanish» или любой другой проект. По той же причине вы обычно не называете свои функции и переменные такими.

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

Так почему же мы используем неописательные кодовые имена?

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

РЕДАКТИРОВАТЬ:

Чтобы дать вам некоторый контекст: Gandalf - это проект, который переносит код на 64 бита. Callanish - это то, что переносит его на Android ... Я бы лучше назвал первый филиал 64bitporting, а второй androidporting. Возможно, к нему прикреплен суффикс, обозначающий целевую версию, которую мы планируем отправить. Таким образом, каждый будет знать по имени, что это такое.

Рассматриваемые серверы - это образы виртуальных машин, на которых мы тестируем продукт ... Хотя я не знаю физическую машину, на которой он работает. Так что называть их windowsxp_32, windows7_64, debian_32 или solaris_64 вполне нормально.

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

Отказ от ответственности: это будет содержать некоторые мнения и анекдотические истории из-за вопроса.

В месте, где я работал пару лет назад, все наши серверы были названы в честь лун и частей тела. "Рея", "Миранда", "Легкие", "Почки" и т. Д.

Вверху, как и вы, решили, что все это немного глупо, и мы должны изменить их на более «описательные» имена, такие как «arc-sql-w-4» или «lon-web-lin-2». Это было встречено с большим сопротивлением. Но это прошло. Мы переименовали все.

Так что пошло не так?

Раньше мы наверняка знали, какие машины были основными базами данных, а какие - рабами, потому что мы помнили «голову», контролируемую сердцем », или что« Tarvos »был сервером приложений для X. Что угодно. Теперь мы должны были вспомнить неясную кучу символов, которые частично, но не полностью описывали машину, которую мы искали. Нам пришлось узнать из таблицы поиска в наших головах, что «lon-web-lin-1» является сервером приложений для продукта A и «lon-web-lin-2» для продукта B.

Это похоже на причины, по которым вы должны использовать пароли типа FartDownTrousersForALivingDoYou? вместо 43gH5 # € 1. Люди хорошо запоминают слова, а не случайные груды мусора. Слова - это символы, которые относятся к вещам.

Другая (возможно, более практичная) проблема заключается в том, что вы привязываете свои DNS и имена серверов к их функциям. Это означает, что вы не можете изменить функцию без изменения названия. Для нас это также касается физического местоположения и операционной системы. Что является огромной болью в заднице.

Кроме того, и это последний пункт. Имена куда веселее.

А как насчет названий проектов?

Ну а вместо "Project Gandalf" что вы предлагаете? «Спроектировать прототип функции X и посмотреть, сможем ли мы превратить ее в продукт»? Что, если масштаб проекта изменится, мы потом переименуем проект? Опять же, имена являются сокращенными символами, которые относятся к вещам.

Называть вещи по их свойствам - принципиально плохая идея. Причина в том, что свойства , по определению, являются изменчивыми явлениями, в то время как идентичность вещи остается неизменной, даже если свойства изменяются.

Кто-то решает, что файловый сервер следует перенести на Linux? Если его зовут «Аполлон», это не проблема. Если имя ссылается на «windows», то оно либо вводит в заблуждение, либо должно быть изменено повсеместно с большими затратами или риском. Вы вводите новый формат вывода? Ради любви к Богу, не называйте это «новым форматом»! Это будет в конечном итоге заменить еще раз, и даже новый формат нужно будет еще более описательный имя , чтобы отличить его. Либо назовите его «3», чтобы потом повысить его до «4», либо «золотым», чтобы повысить его до «платинового».

(Дополнительная причина заключается в том, что имена, состоящие из кусочков информации, являются ужасно неприятными. Никто не хочет работать на компьютере с именем «PC-Marketing-Windows7-143» - они возьмут «Аполлона» или даже «Вакха» над этим в любой день. Но главное - это разделение личности / собственности.)

По моему опыту, есть 3 причины:

1. Когда вам приходится называть множество похожих вещей, бывает сложно найти уникальные описательные имена для всех них. Людям нужен короткий уникальный способ обращения к нему, и мы лучше используем имена, чем цифры (если число не очень короткое). Когда вы даете ему имя, оно, как правило, приобретает индивидуальность, поэтому вы помните, что сервер Gandalf лучше, чем SERWIN15AB23, с ненадежным разъемом питания. Также менее вероятно, что вы перепутаете двух из них с опечаткой.

2. Процесс именования может быть веселым. Некоторые компании делают это с помощью голосования. Другим людям нравится придумывать уникальные имена. Просто спросите любого родителя.

3. Что касается внешних проектов, то обычно маркетинг определяет, как их зовут, и обычно они делают это непосредственно перед его отправкой. Когда Microsoft решила назвать последнюю ОС «Windows 10»? Я сомневаюсь, что это всегда называлось так. Возможно, до этого проект находился в разработке еще долгое время, и в некоторых случаях вы хотите его запутать, чтобы люди за пределами компании не знали, о чем вы говорите.

Описательное наименование - это сложно, гораздо проще, если у вас уже есть тема, которая автоматически поставляется со списком слов, которые вы можете использовать.

Когда у вас есть несколько одного и того же объекта , называя их foo1.6, foo1.2и т.д. быстро становится запутанным / склонной к ошибкам. Например, когда вам нужно запустить тест, Virgoвы быстро заметите ошибку, если это случилось Cancer.

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

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

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

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

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

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

Высокий контекст также может быть смешнее, и в этом есть некоторая ценность.

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

Точно так же, если вы дадите своим серверам бессмысленные имена, то никто, кроме авторизованных пользователей, не поймет, что на них.

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

Давайте установим, что описательность происходит от вызова вещей их ролью , целью. По тому, что они делают . Например, довольно ясно, что делает «резак». Теперь это может быть топор, лазер или нож. Это не так важно. И лазер также может быть «указателем», а топор также может быть «декоратором», а нож - «прокалывателем».

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

Если вы не работаете над тем, как компонент DoesXвыполняет X, это не ваше дело. Если это ваша работа, то вы все равно столкнетесь с ней.

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

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

Вторая причина в том, что он создает дух товарищества. Если команда выберет имя, оно может выбрать то, что им всем нравится. Это незаметно, но повышает командный дух, когда вы работаете над проектом с именем Viper, Gimley, Boba или Bugatti, а не с проектом «Обновления бухгалтерского учета Q3». У меня был друг, который работал в команде с кучей автолюбителей. Их любимым ритуалом начала проекта было выбрать, какую машину они будут использовать в качестве кодового названия проекта.

Я всегда думал, что это то, что делается в основном потому, что это забавляет людей. Средства массовой информации заставляют людей придавать значение тому, чтобы скрываться в темноте, а не работать при свете дня. В 5 лет у нас есть «Специальный агент Осо»; в 15 лет это Джеймс Бонд. Секретность создает впечатление важности для других мирских действий людей (например, программирование компьютера).

Кроме того, кто-то сделал логотип для «Longhorn», когда это было кодовое имя Microsoft ( http://en.wikipedia.org/wiki/File:Windows_Longhorn_logo.svg ). Зачем кому-то делать логотип для кодового имени, которое никогда не будет частью маркетинговой деятельности? Опять же, люди делают такие вещи, потому что это забавляет их. Играть в Photoshop легче / веселее, чем на самом деле.

вполне может быть система, которую вы просто не знаете.
Одна компания, в которой я работал, использовала имена лауреатов Нобелевской премии для всех своих серверов. Различные Нобелевские премии обозначали разные категории серверов.
Тестовые серверы могут быть названы в честь победителей математики, серверы баз данных в честь литературных победителей, почтовые серверы в честь победителей лекарств и т. Д.
Для тех, кто не знаком с соглашением об именах, имена казались совершенно случайными (особенно потому, что большинство людей не знают всех сотни нобелевских лауреатов за десятилетия).

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

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