Eu acho que o uso de codinomes é bastante difundido. Nossa empresa também está usando-os.
Mas minha principal preocupação é que esses nomes geralmente não são documentados em nenhum lugar. E o significado é espalhado pela palavra da boca. E os nomes não têm nada a ver com a função da ferramenta ou entidade em que estão nomeados.
Vejo o padrão em que as máquinas de teste internas têm o nome de constelações; os servidores públicos têm o nome de deuses gregos. E os projetos têm nomes de lugares ou o nome de alguma estrela de cinema ou nome de personagem escolhido aleatoriamente. Mas nenhuma informação está diretamente disponível a partir do nome, sejam as máquinas Windows ou Linux; Servidores de 32 ou 64 bits. Ou sobre o que é o projeto.
Só tenho uma sensação ruim quando vejo a mensagem de confirmação do VCS de que alguém acabou de ramificar o projeto "Gandalf" ou o projeto "Callanish" ou qualquer outro projeto. Pela mesma razão, você geralmente não nomeia suas funções e variáveis assim.
Propus que usássemos nomes mais descritivos, pelo menos para as novas entidades, mas enfrentei uma oposição muito forte. Aparentemente, todos na organização, exceto eu, adoram nomear coisas assim.
Então, por que usamos nomes de código não descritivos?
Não me interpretem mal. Não tenho problemas em nomear versões e marcos do programa ou ter um bom nome de produto por razões de marketing. Mas em todos os outros lugares eu gostaria de ver nomes descritivos.
EDITAR:
Para lhe dar um pouco de contexto: Gandalf é um projeto que porta o código de 64 bits. Callanish é o que o move para Android ... Prefiro chamar o antigo ramo 64bitporting e o último androidporting. Talvez um sufixo esteja associado a ele, indicando a versão de destino que planejamos enviá-lo. Então todo mundo saberia pelo nome o que é.
Os servidores em questão são imagens de máquinas virtuais nas quais testamos o produto ... Não conheço a máquina física na qual ele realmente é executado. Portanto, chamá-los de windowsxp_32, windows7_64, debian_32 ou solaris_64 é totalmente bom.
fonte
Respostas:
Não fazemos referência às pessoas por suas características, pois leva o dia inteiro para listá-las com detalhes suficientes para serem inequívocas e as características podem mudar. E se eles cortarem o cabelo? Em vez disso, damos nomes a eles. Além disso, as pessoas são melhores em lembrar palavras do que fluxos de símbolos aleatórios.
Isenção de responsabilidade: isso conterá algumas opiniões e histórias contadas devido à pergunta.
Em um local em que trabalhei alguns anos atrás, todos os nossos servidores receberam o nome de luas e partes do corpo. "Rhea", "Miranda", "pulmão", "rim" etc.
No alto, decidimos, como você, que tudo isso era um pouco bobo e devemos alterá-los para nomes mais "descritivos", como "arc-sql-w-4" ou "lon-web-lin-2". Isso foi recebido com muita oposição. Mas passou. Renomeamos tudo.
Então, o que deu errado?
Anteriormente, saberíamos de antemão quais máquinas eram os principais bancos de dados e quais eram os escravos, porque nos lembrávamos de "cabeça" controlada por "coração" ou que "Tarvos" era um servidor de aplicativos para o X. Tanto faz. Agora tínhamos que lembrar uma pilha obscura de símbolos que descreviam parcialmente, mas não totalmente, a máquina que estávamos procurando. Tínhamos que saber, através de alguma tabela de pesquisa em nossas cabeças, que "lon-web-lin-1" era um servidor de aplicativos para o produto A e "lon-web-lin-2" para o produto B.
É semelhante aos motivos pelos quais você deve usar senhas como FartDownTrousersForALivingDoYou? em vez de 43gH5 # € 1. As pessoas são boas em lembrar palavras, e não pilhas aleatórias de lixo. Palavras são símbolos que se referem a coisas.
Outro problema (sem dúvida mais prático) é que você está vinculando os nomes de DNS e servidor às funções deles. O que significa que você não pode alterar a função sem alterar o nome. Para nós, isso incluía localização física e sistema operacional também. O que é uma enorme dor na bunda.
Além disso, e este é o último ponto. Os nomes são muito mais divertidos.
E os nomes dos projetos?
Bem, em vez de "Projeto Gandalf", o que você propõe? "Projete a função protótipo X e veja se podemos evoluí-la para um produto"? E se o escopo do projeto mudar, renomeamos o projeto? Novamente, nomes são símbolos abreviados que se referem a coisas.
fonte
db3.todoapp
é mais informativo se o servidor apenas manipulartodoapp
. Se o marketing decidir chamar o aplicativo "Organizer Pro" e você tiver outros 8 aplicativos no servidor, o gerenciamento dos nomes será bastante complicado.Nomear as coisas por suas propriedades é uma idéia fundamentalmente ruim. A razão é que as propriedades são, por definição, fenômenos mutáveis, enquanto a identidade de uma coisa permanece a mesma, mesmo que as propriedades sejam alteradas.
Alguém decide que o servidor de arquivos deve ser migrado para o Linux? Se o nome for "Apollo", isso não é problema. Se o nome referisse "janelas", ele se tornaria enganoso ou teria que ser alterado em todos os lugares com grandes despesas ou riscos. Você está introduzindo um novo formato de saída? Pelo amor de Deus, não chame de 'newFormat'! Ele será substituído novamente mais uma vez, e o formato ainda mais recente precisará de um nome ainda mais descritivo para distingui-lo. Você pode chamá-lo de '3', para posteriormente aumentá-lo para '4' ou 'ouro' para atualizar para 'platina'.
(Um motivo adicional é que os nomes compostos por pepitas de informação são muito feios. Ninguém quer trabalhar em um computador chamado "PC-Marketing-Windows7-143" - eles aceitarão "Apollo" ou mesmo "Bacchus" por causa disso. qualquer dia. Mas o ponto principal é a divisão identidade / propriedade.)
fonte
Hermes
então sim, é mais reconhecível quefunctionWithTenLinesOfCode
. Pessoalmente, eu diria que simprint
.print_left_aligned_to_CRT_monitor()
Cathy()
. nota: eu vi pessoalmente o código de produção com nomes de funções e variáveis citando as letras do Guns & Roses e sou culpado de escrever o código de produção com nomes de variáveis e funções que fazem referência a Buffy.Existem três razões, na minha experiência:
Quando você precisa nomear muitas coisas semelhantes, pode ser difícil encontrar nomes descritivos exclusivos para todas elas. As pessoas precisam de uma maneira única e curta de se referir a ela, e somos melhores em usar nomes do que em números (a menos que o número seja muito curto). Quando você nomeia um nome, ele tende a ter uma personalidade em sua mente, para que você lembre-se de que o servidor Gandalf é aquele com o conector de energia esquisito melhor que o SERWIN15AB23. Também é menos provável que você confunda dois deles com um erro de digitação.
O processo de nomeação pode ser divertido. Algumas empresas fazem isso com um voto. Outras pessoas gostam de criar nomes únicos. Basta perguntar a qualquer pai.
Para projetos externos, geralmente é o marketing que decide qual é o nome e, normalmente, ele faz isso antes de ser lançado. Quando a Microsoft decidiu chamar o SO mais recente "Windows 10"? Duvido que sempre tenha sido chamado assim. O projeto pode estar em desenvolvimento por um longo tempo antes disso e, em alguns casos, você deseja ofuscá-lo para que pessoas de fora da empresa não saibam do que você está falando.
fonte
A nomeação descritiva é difícil ™, é muito mais fácil se você já tiver um tema que vem automaticamente com uma lista de palavras que você pode usar.
Quando você tem múltiplas do mesmo objeto nomeando-os
foo1.6
,foo1.2
etc. rapidamente se confundindo / propenso a erros. Por exemplo, quando você precisar executar seu testeVirgo
, notará rapidamente o erro se estiver ativandoCancer
.Também é uma reunião divertida quando as convenções de nomenclatura são lançadas e a decisão é tomada para basear os nomes das salas de conferências de acordo com os gêneros musicais e o nome da lanchonete
Salsa
.fonte
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.
Muito verdadeiro. Mas só porque é mais fácil, não significa que seja bom a longo prazo. O que você está dizendo não é diferente de não fazer um design de API adequado, porque é muito mais fácil produzir a funcionalidade.Isso pode estar relacionado ao alto contexto ou à cultura de baixo contexto . Toda empresa, organização ou equipe tem sua própria cultura. Cultura de contexto alta ou baixa significa quanta informação uma cultura gosta de se relacionar explicitamente e quanto as pessoas devem tirar do contexto.
Nomear todos os serviços com nomes de referências culturais fornece alguma flexibilidade, mas também carece de explicações. Tem que haver uma palavra da boca ou "conhecimento tribal" que complemente os nomes - isto é, o contexto do serviço. Eu já vi situações em que, por exemplo, há o servidor "fizzbuzz" ou o serviço "marcopolo" que ninguém sabe o que faz, mas recebe tráfego, por isso deve fazer alguma coisa.
Como sou uma pessoa de baixo contexto, costumo escolher nomes simples e explícitos que fornecem contexto sobre a finalidade de um servidor ou serviço. Também escrevo "código de auto-documentação", onde tomo cuidado para nomear meu código para torná-lo mais legível.
No momento, estou trabalhando em uma loja de alto contexto, onde todos os serviços têm o nome de Transfomers. Suspiro. Pelo menos eles usam os nomes de forma consistente.
Portanto, parece mais um valor cultural, mas as práticas técnicas se adaptarão às preferências culturais.
Contexto alto também pode ser mais engraçado, e há algum valor nisso.
fonte
Um motivo para codinomes é ofuscação. Se você tornar o nome de um projeto sem sentido, poderá falar sobre isso em público sem que mais ninguém entenda o que está discutindo.
Da mesma forma, se você der nomes sem sentido aos seus servidores, ninguém, exceto os usuários autorizados, terá alguma idéia do que está neles.
fonte
A questão importante é: o que é descritivo? As outras respostas fizeram um ótimo trabalho ilustrando o que não é descritivo.
Vamos estabelecer que a descritividade deriva de chamar as coisas por seu papel , seu propósito. Pelo que eles fazem . Por exemplo, é bem claro o que um "cortador" faz. Agora poderia ser um machado, um laser ou uma faca. Não importa tanto. E um laser também pode ser um "ponteiro", um machado também pode ser um "decorador" e uma faca também pode ser um "perfurador".
Assim, como outros apontaram, a relação entre as propriedades de algo e a tarefa que ele realiza é relativamente frouxa. Portanto, o SO que faz parte do nome do servidor não é descritivo , é uma distração do verdadeiro objetivo.
A menos que seja seu trabalho trabalhar em como o componente
DoesX
realiza o X, isso não é da sua conta. Se é o seu trabalho, você será imediatamente confrontado com ele de qualquer maneira.Como o maníaco do rachet apontou, às vezes é difícil encontrar nomes descritivos. Mas, na maioria das vezes, isso é um sinal de não ter entendido o que as coisas fazem, que você deve nomear. Antes de ter esse entendimento, você provavelmente não deve se preocupar com o que faz com o que não conhece;)
fonte
http-blog-db-failover
para uma máquina que hospeda um banco de dados de failover de um site que hospeda blogs; passar do Linux para o Windows ou do MongoDB para o CouchDB não afetará o nome, nem as decisões de marketing. )A primeira razão é que pode ser curta e memorável. Se você pensar quantas vezes vai dizer ou escrever o nome do projeto, economize bastante tempo se houver um nome breve que todos saibam e entendam.
A segunda razão é que ela cria camaradagem. Se a equipe escolher o nome, poderá escolher um que todos gostem. É sutil, mas aumenta o moral da equipe quando você está trabalhando em um projeto chamado Viper, Gimley, Boba ou Bugatti, em vez de um projeto chamado 'Q3 Accounting Updates'. Eu tinha um amigo que trabalhava em uma equipe com muitos entusiastas de carros. O ritual de início do projeto favorito era escolher qual carro eles usariam como o nome do código do projeto.
fonte
Eu sempre pensei que isso é algo que é feito principalmente porque diverte as pessoas. As pessoas são condicionadas pela mídia a atribuir valor a andar no escuro versus operar à luz do dia. Aos 5 anos, temos o "Agente Especial Oso"; aos 15 anos é James Bond. O segredo empresta um ar de importância às atividades mundanas das pessoas (por exemplo, programar um computador).
De maneira semelhante, alguém criou um logotipo para "Longhorn" quando esse era um codinome da Microsoft ( http://en.wikipedia.org/wiki/File:Windows_Longhorn_logo.svg ). Por que alguém criaria um logotipo para um codinome que não pretende realmente fazer parte de qualquer esforço de marketing? Novamente, as pessoas fazem esse tipo de coisa porque as diverte. Brincar no Photoshop é mais fácil / divertido do que realmente fazer um trabalho real.
fonte
pode haver um sistema que você simplesmente não conhece.
Uma empresa em que trabalhei usou nomes de ganhadores do Prêmio Nobel em todos os seus servidores. Diferentes prêmios Nobel indicaram diferentes categorias de servidores.
Servidores de teste pode ser nomeado após vencedores matemática, servidores de banco de dados após vencedores literatura, servidores de correio após vencedores medicina, etc. etc.
a alguém não familiarizado com a convenção de nomenclatura, os nomes parecia completamente aleatório (especialmente porque a maioria das pessoas não sabem todos aqueles centenas de ganhadores do prêmio Nobel ao longo das décadas).
Eu usei um sistema semelhante em casa, nomeando computadores como caças a jato, servidores após bombardeiros e volumes de disco após vulcões.
O mesmo poderia ser feito com software, nomeie versões de produção depois de árvores, versões beta depois de flores, etc. etc.
fonte