Чому ми використовуємо не описові внутрішні кодові назви? [зачинено]

Я думаю, що використання кодових імен досить поширене. Наша компанія теж їх використовує.

Але моє основне занепокоєння полягає в тому, що ці імена зазвичай ніде не задокументовані. А значення поширюється із уст в уста. І назви не мають нічого спільного з функцією інструменту чи сутності, яку він назвав.

Я бачу закономірність того, що внутрішні тестові машини названі на честь сузір'їв, а загальнодоступні сервери мають ім'я грецьких богів. А проекти названі на місцях чи назви якоїсь випадково вибраної зірки фільму чи імені персонажа. Але немає відомостей, безпосередньо доступних від назви, чи є машини Windows чи Linux; 32 або 64 бітні сервери. Або про який проект.

У мене просто неприємне відчуття кишки, коли я бачу повідомлення про поступки VCS про те, що хтось просто розгалужував проект "Гендальфа" або проект "Калланіш" або будь-який інший проект. Просто з тієї ж причини ти зазвичай не називаєш такі функції та змінні.

Я запропонував використовувати більш описові назви, принаймні для нових утворень, але я зіткнувся з дуже сильною опозицією. Мабуть, всі в організації, крім мене, люблять називати такі речі.

То чому ми використовуємо не описові кодові назви?

Не зрозумійте мене неправильно У мене немає проблем з назвою версій програми та етапів, або з приємною назвою продукту з маркетингових причин. Але у всіх інших місцях я б хотів побачити описові назви.

Редагувати:

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

Розглянуті сервери - це зображення віртуальних машин, на яких ми тестуємо продукт ... Я не знаю, на якій фізичній машині він працює. Тож називати їх windowsxp_32, windows7_64, debian_32 або solaris_64 - це цілком добре.

Ми не посилаємось на людей за їх характеристиками, оскільки потрібен цілий день, щоб перерахувати їх досить детально, щоб бути однозначним, і характеристики можуть змінюватися. Що робити, якщо вони отримають стрижку? Натомість ми даємо їм імена. Також люди краще запам'ятовують слова, ніж потоки випадкових символів.

Відмова: Це буде містити певну думку та анекдотичні казки через запитання.

У місці, де я працював пару років тому, всі наші сервери були названі на честь лун та частин тіла. "Rhea", "Miranda", "легеня", "нирка" і т.д.

Нагорі високо, як і ви, вирішив, що це все було трохи нерозумно, і ми повинні змінити їх на більш "описові" назви, такі як "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 легше / веселіше, ніж насправді робити справжню роботу.

цілком може існувати система, яку ви просто не знаєте.
Одна компанія, в якій я працював, використовувала імена нобелівських призерів для всіх їх серверів. Різні Нобелівські премії вказували різні категорії серверів.
Тестові сервери можуть бути названі на честь переможців математики, серверів баз даних після переможців літератури, поштових серверів після переможців ліків тощо. Ім’ям,
хто не знайомий з умовами іменування, імена здавалися абсолютно випадковими (особливо, оскільки більшість людей не знає всіх сотні лауреатів Нобелівської премії протягом десятиліть).

Я вдома використовував подібну систему, називав комп’ютери за реактивними винищувачами, сервери після бомбардувальників та об'єм диска після вулканів.

Те саме можна зробити з програмним забезпеченням, версії для виробництва назв після дерев, бета-версії після квітів тощо тощо.