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

16

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

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

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

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

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

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

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

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

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

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

Calmarius
источник
6
То, что для вас является описательным, может оказаться недостаточно описательным (или кратким) для кого-то другого. Имя есть имя есть имя. Нет путаницы или разногласий.
Робби Ди
1
Так много ответов, и все же, если вы зададите вопрос «Должен ли я называть свои серверы по назначению или по греческим богам?», Я подозреваю / надеюсь, что цель будет рекомендована. И да, fileserver4 легче запомнить, чем Aphrodita, когда речь идет о запоминании серверов с ftp.
Vorac
2
Этот вопрос кажется не по теме, поскольку он не связан с разработкой программного обеспечения.
Майк Партридж
4
Что в имени? То, что мы называем розой по любому другому слову, будет пахнуть как сладкое.
Калеб
3
Я надеюсь, что ветвь Gandalf не является кодовым названием для среды модульного тестирования. Все, что проходит через это, НЕ ПРОЙДЕТ!
КорсиКа

Ответы:

25

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

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

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

Вверху, как и вы, решили, что все это немного глупо, и мы должны изменить их на более «описательные» имена, такие как «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 и посмотреть, сможем ли мы превратить ее в продукт»? Что, если масштаб проекта изменится, мы потом переименуем проект? Опять же, имена являются сокращенными символами, которые относятся к вещам.

Том
источник
5
Похоже, вы изменили описательные метафоры для неописательных иероглифов. Вы должны были применить шаблон именования, чтобы было ясно, какой продукт работает на каком сервере. Вот что значит быть «описательным»;)
back2dos
9
@ back2dos - А когда новое приложение развертывается на сервере или существующее приложение перемещается на другой сервер, переименовываете ли вы все затронутые серверы? Как насчет того, когда Продукт A будет переименован (поскольку мы не используем кодовые имена)? Собираетесь ли вы менять везде, где имя хранится на клиенте? Или вы собираетесь оставить вводящие в заблуждение псевдонимы DNS, чтобы минимизировать масштаб изменений?
Джастин Кейв
5
@ back2dos - переименование серверов (и обновление всех клиентов) каждый раз, когда развертывается новое приложение, становится довольно болезненным довольно быстро. Что происходит при развертывании 10-го приложения на определенном сервере? Что происходит, когда у вас есть сотни клиентских компьютеров, которые имеют ссылки на определенное имя сервера? db3.todoappявляется более информативным , если сервер обрабатывает только todoapp. Если маркетинг решит назвать приложение «Organizer Pro» и у вас есть 8 других приложений на сервере, управление именами будет довольно сложным.
Джастин Кейв
4
Кроме того, что происходит, когда машины имеют более одной функции? Имена либо становятся неуправляемо большими, либо не могут точно описать.
Том
3
С back2dos сложно не согласиться. «неописательные иероглифы» - это именно то, о чем я думал, читая ваши примеры. Различия между ролью и идентичностью, которые делает back2dos, также особенно актуальны. В моей компании серверы названы в соответствии с их ролями, и такое имя, как «http-blog-db-failover», кажется гораздо более явным, чем «Гермиона», и имя не изменится, когда я переключусь с MongoDB на CouchDB или когда маркетинг решает изменить коммерческое название веб-сайта, на котором размещены блоги.
Арсений Мурзенко
10

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

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

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

Килиан Фот
источник
5
Описательные имена описывают не свойства, а цели . Если вы вызываете функцию, которая отображает вывод, Hermesтогда да, это более узнаваемо, чем functionWithTenLinesOfCode. Лично я бы назвал это printвсе же.
back2dos
@ back2dos Примеры, которые дает OP, похоже, описывают эквивалентprint_left_aligned_to_CRT_monitor()
Izkata
@Izkata: Вы должны признать, это намного лучше, чем Cathy(). примечание: я лично видел рабочий код с именами функций и переменных, цитирующими слова Guns & Roses, и виновен в написании рабочего кода с именами переменных и функций, ссылающимися на Баффи.
Slebetman
10

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

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

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

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

Скотт Уитлок
источник
5
Также стоит добавить, что имена могут быть адаптированы к рассматриваемой задаче. Гэндальф может быть сервером сборки "там, где происходит волшебство", Цербер может быть брандмауэром, Гефест, сервер разработки и т. Д. ... очень сложно связать числа с функциями
Liath
1
Кстати: внутреннее имя для «Windows 10» на самом деле «Windows NT 6.4». Но маркетинг никогда не признал бы, что 6.0, или «Vista», была последней версией, в которой ядро ​​операционной системы подверглось серьезной переработке.
Филипп
@Philipp просто введите "ver" в командную строку компьютера с Windows 7 - 6.1 (Vista SP1, который всегда был шуткой), не зная, какая Windows 8 не в моей голове.
Лиат
Windows 8.1 Pro (я уверен, что этот ПК не имеет Обновления 1): 6.3.9600 msdn.microsoft.com/en-us/library/windows/desktop/…
WernerCD
@Philipp AFAIK, это сделано по причинам обратной совместимости, это не отражает, насколько сильно изменилось ядро.
svick
6

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

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

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

чокнутый урод
источник
1
Descriptive naming is hard™, it's much easier if you already have a theme which automatically comes with a list of words you can use.Очень верно. Но то, что это легче, не значит, что это хорошо в долгосрочной перспективе. То, что вы говорите, мало чем отличается от правильного проектирования API, потому что гораздо проще просто использовать функциональность.
back2dos
4

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

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

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

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

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

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

обкрадывать
источник
3

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

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

Саймон Б
источник
2

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

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

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

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

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

back2dos
источник
+1, а как насчет добавления примера? Вы можете использовать пример, который я использовал при комментировании вопроса ( http-blog-db-failoverдля машины, на которой размещена база данных отработки отказа веб-сайта, на котором размещаются блоги; переход с Linux на Windows или с MongoDB на CouchDB не повлияет на название, равно как и маркетинговые решения. )
Арсений Мурзенко
2

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

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

epotter
источник
2

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

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

user1172763
источник
1

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

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

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

jwenting
источник