Je pense que l'utilisation des noms de code est assez répandue. Notre entreprise les utilise également.
Mais ma principale préoccupation est que ces noms ne sont généralement documentés nulle part. Et le sens se répand par le bouche à oreille. Et les noms n'ont rien à voir avec la fonction de l'outil ou de l'entité qui le nomme.
Je vois le modèle selon lequel les machines de test internes sont nommées d'après les constellations, les serveurs publics sont nommés d'après les dieux grecs. Et les projets sont nommés d'après des lieux ou le nom d'une star de cinéma ou d'un nom de personnage choisi au hasard. Mais aucune information directement disponible à partir du nom, que les machines soient Windows ou Linux; Serveurs 32 ou 64 bits. Ou quel est le projet.
J'ai juste un mauvais pressentiment quand je vois le message de validation du VCS que quelqu'un vient de brancher le projet "Gandalf" ou le projet "Callanish" ou n'importe quel projet. Juste pour la même raison, vous ne nommez généralement pas vos fonctions et variables comme ça.
J'ai proposé d'utiliser des noms plus descriptifs, au moins pour les nouvelles entités, mais j'ai été confronté à une très forte opposition. Apparemment, tout le monde dans l'organisation, sauf moi, aime nommer des trucs comme ça.
Alors pourquoi utilisons-nous des noms de code non descriptifs?
Ne vous méprenez pas, je n'ai aucun problème à nommer les versions et les jalons du programme, ou à avoir un joli nom de produit pour des raisons de marketing. Mais à tous les autres endroits, j'aimerais mieux voir des noms descriptifs.
ÉDITER:
Pour vous donner un peu de contexte: Gandalf est un projet qui porte le code 64 bits. Callanish est celui qui le porte sur Android ... Je préfère appeler l'ancienne branche 64bitporting et la dernière androidporting. Peut-être un suffixe attaché à celui-ci indiquant la version cible que nous prévoyons de l'expédier. Donc, tout le monde saurait par son nom ce que c'est.
Les serveurs en question sont des images de machines virtuelles sur lesquelles nous testons le produit ... Je ne connais pas la machine physique sur laquelle il fonctionne réellement. Donc, les appeler windowsxp_32, windows7_64, debian_32 ou solaris_64 est tout à fait correct.
la source
Réponses:
Nous ne référençons pas les gens par leurs caractéristiques, car il faut toute la journée pour les énumérer suffisamment en détail pour être sans ambiguïté et les caractéristiques peuvent changer. Et s'ils se font couper les cheveux? Au lieu de cela, nous leur donnons des noms. De plus, les gens se souviennent mieux des mots que des flux de symboles aléatoires.
Avis de non-responsabilité: cela contiendra des opinions et des anecdotes en raison de la question.
Dans un endroit où j'ai travaillé il y a quelques années, tous nos serveurs portent le nom de lunes et de parties du corps. "Rhea", "Miranda", "poumon", "rein" etc.
En haut, vous avez décidé, comme vous, que tout cela était un peu idiot et nous devrions les changer pour des noms plus "descriptifs" comme "arc-sql-w-4" ou "lon-web-lin-2". Cela a rencontré beaucoup d'opposition. Mais c'est passé. Nous avons renommé tout.
Alors qu'est-ce qui a mal tourné?
Auparavant, nous savions du haut de nos têtes quelles machines étaient les bases de données primaires et quels étaient les esclaves parce que nous nous souvenions de la «tête» contrôlée par «cœur» ou que «Tarvos» était un serveur d'applications pour X. Maintenant, nous devions nous souvenir d'une pile obscure de symboles qui décrivait partiellement, mais pas complètement la machine que nous recherchions. Nous devions savoir via une table de recherche dans nos têtes que "lon-web-lin-1" était un serveur d'applications pour le produit A et "lon-web-lin-2" pour le produit B.
C'est similaire aux raisons pour lesquelles vous devriez utiliser des mots de passe comme FartDownTrousersForALivingDoYou? au lieu de 43gH5 # 1 €. Les gens se souviennent bien des mots, pas des tas d'ordures aléatoires. Les mots sont des symboles qui se réfèrent à des choses.
Un autre problème (sans doute plus pratique) est que vous liez vos noms DNS et de serveur à leurs fonctions. Ce qui signifie que vous ne pouvez pas changer la fonction sans changer le nom. Pour nous, cela comprenait également l'emplacement physique et le système d'exploitation. Ce qui est une énorme douleur dans le cul.
Aussi, et c'est le dernier point. Les noms sont bien plus amusants.
Et les noms de projets?
Eh bien, au lieu de "Project Gandalf" que proposez-vous? "Projetez la fonction prototype X et voyez si nous pouvons la transformer en produit"? Et si la portée du projet change, renommons-nous alors le projet? Encore une fois, les noms sont des symboles sténographiques qui renvoient à des choses.
la source
db3.todoapp
est plus informatif si le serveur ne gère quetodoapp
. Si le marketing décide d'appeler l'application "Organizer Pro" et que vous avez 8 autres applications sur le serveur, la gestion des noms devient assez compliquée.Nommer les choses par leurs propriétés est une idée fondamentalement mauvaise. La raison en est que les propriétés sont, par définition, des phénomènes modifiables, tandis que l' identité d'une chose reste la même, même si les propriétés sont modifiées.
Quelqu'un décide que le serveur de fichiers doit être migré vers Linux? Si son nom est "Apollo", ce n'est pas un problème. Si le nom faisait référence à "windows", il deviendrait alors trompeur ou devrait être changé partout à grands frais ou à grands risques. Vous introduisez un nouveau format de sortie? Pour l'amour de Dieu, ne l'appelez pas 'newFormat'! Il sera finalement remplacé une fois de plus, et le format encore plus récent aura besoin d'un nom encore plus descriptif pour le distinguer. Vous pouvez soit l'appeler «3», afin de pouvoir ensuite l'augmenter à «4», ou «or» afin que vous puissiez passer à «platine».
(Une raison supplémentaire est que les noms composés de pépites d'informations sont laids. Personne ne veut travailler sur un ordinateur nommé "PC-Marketing-Windows7-143" - ils prendront "Apollo" ou même "Bacchus" par-dessus n’importe quel jour. Mais le point principal est la division identité / propriété.)
la source
Hermes
alors oui, elle est plus reconnaissable quefunctionWithTenLinesOfCode
. Personnellement, je l'appelleraisprint
cependant.print_left_aligned_to_CRT_monitor()
Cathy()
. note: J'ai personnellement vu du code de production avec des noms de fonction et de variable citant les paroles de Guns & Roses et je suis coupable d'avoir écrit du code de production avec des noms de variable et de fonction faisant référence à Buffy.Il y a 3 raisons, selon mon expérience:
Lorsque vous devez nommer beaucoup de choses similaires, il peut être difficile de trouver des noms descriptifs uniques pour chacun d'eux. Les gens ont besoin d'une façon unique et brève de s'y référer, et nous sommes meilleurs dans l'utilisation des noms que dans les nombres (sauf si le nombre est très court). Lorsque vous lui donnez un nom, il a tendance à prendre une personnalité dans votre esprit, vous vous souviendrez donc que le serveur Gandalf est celui avec le connecteur d'alimentation feuilleté meilleur que SERWIN15AB23. Il est également moins probable que vous en confondiez deux avec une faute de frappe.
Le processus de dénomination peut être amusant. Certaines entreprises le font avec un vote. D'autres personnes aiment trouver des noms uniques. Demandez à n'importe quel parent.
Pour les projets externes, c'est généralement le marketing qui décide quel est le nom, et normalement ils le font juste avant l'expédition. Quand Microsoft a-t-il décidé d'appeler le dernier système d'exploitation "Windows 10"? Je doute que cela ait toujours été appelé ainsi. Le projet peut être en développement depuis longtemps avant cela, et dans certains cas, vous voulez le masquer afin que les personnes extérieures à l'entreprise ne sachent pas de quoi vous parlez.
la source
Le nommage descriptif est difficile ™, c'est beaucoup plus facile si vous avez déjà un thème qui vient automatiquement avec une liste de mots que vous pouvez utiliser.
Lorsque vous avez plusieurs du même objet en les nommant
foo1.6
,foo1.2
etc. devient rapidement confus / sujettes à des erreurs. Par exemple, lorsque vous devez exécuter votre test,Virgo
vous remarquerez rapidement l'erreur si vous vous trouvezCancer
.Cela permet également une réunion divertissante lorsque les conventions de dénomination sont déployées et que la décision est prise de baser les noms des salles de conférence sur les genres musicaux et que vous nommez la cafétéria
Salsa
.la source
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.
Très vrai. Mais ce n'est pas parce que c'est plus facile que c'est bon à long terme. Ce que vous dites n'est pas différent de ne pas faire une bonne conception de l'API, car il est beaucoup plus facile de simplement produire des fonctionnalités.Cela peut être lié à une culture à contexte élevé ou à contexte faible . Chaque entreprise, organisation ou équipe a sa propre culture. Une culture de contexte élevé ou faible signifie la quantité d'informations qu'une culture aime à relier explicitement et la quantité de personnes attendues du contexte.
Nommer tous les services avec des noms issus de références culturelles offre une certaine flexibilité, mais manque également d'explicitation. Il doit y avoir du bouche à oreille ou des «connaissances tribales» qui complètent les noms - c'est-à-dire le contexte du service. J'ai vu des situations où, par exemple, il y a le serveur "fizzbuzz" ou le service "marcopolo" où personne ne sait ce qu'ils font, mais ils obtiennent du trafic, ils doivent donc faire quelque chose.
Je suis une personne à faible contexte, j'ai donc tendance à choisir des noms simples et explicites qui fournissent un contexte sur l'objectif d'un serveur ou d'un service. J'écris également du "code auto-documenté" où je fais attention à nommer mon code pour le rendre plus lisible.
Mais je travaille actuellement dans une boutique à contexte élevé où tous les services portent le nom de Transfomers. Soupir. Au moins, ils utilisent les noms de manière cohérente.
Cela ressemble donc plus à une valeur culturelle, mais les pratiques techniques s'adapteront aux préférences culturelles.
Un contexte élevé peut également être plus drôle, et cela a une certaine valeur.
la source
Une des raisons des noms de code est l'obscurcissement. Si vous rendez le nom d'un projet vide de sens, vous pouvez en parler en public sans que personne d'autre ne comprenne ce dont vous discutez.
De même, si vous donnez à vos serveurs des noms sans signification, personne, à l'exception des utilisateurs autorisés, n'aura la moindre idée de ce qu'ils contiennent.
la source
La question importante est: qu'est-ce qui est descriptif? Les autres réponses ont fait un excellent travail en illustrant ce qui n'est pas descriptif.
Établissons que la descriptivité vient d'appeler les choses par leur rôle , leur but. Par ce qu'ils font . Par exemple, c'est assez clair ce que fait un "cutter". Maintenant, ça pourrait être une hache, un laser ou un couteau. Cela n'a pas tellement d'importance. Et un laser peut également être un "pointeur", une hache peut également être un "décorateur" et un couteau peut également être un "poinçonneur".
Ainsi, comme d'autres l'ont souligné, la relation entre les propriétés de quelque chose et la tâche qu'il accomplit est relativement lâche. Par conséquent, le système d'exploitation faisant partie du nom du serveur n'est pas descriptif , il détourne l'attention du véritable objectif.
À moins que ce soit votre travail de travailler sur la façon dont le composant
DoesX
accomplit X, cela ne vous regarde pas. Si c'est votre travail, vous y êtes de toute façon immédiatement confronté.Comme l'a fait remarquer Rachet Freak, il est parfois difficile de trouver des noms descriptifs. Mais le plus souvent, c'est un signe de ne pas avoir compris ce que font les choses, qu'il faut nommer. Avant d'avoir cette compréhension, vous ne devriez probablement pas vous soucier de la façon dont cela fait ce que vous ne savez pas;)
la source
http-blog-db-failover
pour une machine qui héberge une base de données de basculement d'un site Web hébergeant des blogs; le passage de Linux à Windows ou de MongoDB à CouchDB n'affectera pas le nom, pas plus que les décisions marketing. )La première raison est qu'elle peut être courte et mémorable. Si vous pensez au nombre de fois où vous allez dire ou écrire le nom du projet, vous gagnez beaucoup de temps s'il y a un nom bref que tout le monde connaît et comprend.
La deuxième raison est qu'elle renforce la camaraderie. Si l'équipe arrive à choisir le nom, elle peut en choisir un qu'elle aime tous. C'est subtil, mais cela stimule le moral de l'équipe lorsque vous travaillez sur un projet nommé Viper ou Gimley ou Boba ou Bugatti au lieu d'un projet nommé 'Q3 Accounting Updates'. J'avais un ami qui travaillait dans une équipe avec un tas de passionnés de voitures. Leur rituel de lancement de projet préféré consistait à choisir quelle voiture ils utiliseraient comme nom de code du projet.
la source
J'ai toujours pensé que c'était quelque chose qui se faisait surtout parce que ça amusait les gens. Les gens sont conditionnés par les médias pour attacher de la valeur à se déplacer dans le noir par rapport à opérer à la lumière du jour. À 5 ans, nous avons «l'agent spécial Oso»; à 15 ans, c'est James Bond. Le secret confère un air d'importance aux activités autrement banales des gens (par exemple, la programmation d'un ordinateur).
De manière similaire, quelqu'un a créé un logo pour "Longhorn" alors qu'il s'agissait d'un nom de code Microsoft ( http://en.wikipedia.org/wiki/File:Windows_Longhorn_logo.svg ). Pourquoi quelqu'un créerait-il un logo pour un nom de code qui ne devrait jamais vraiment faire partie d'un effort de marketing? Encore une fois, les gens font ce genre de choses parce que cela les amuse. Jouer dans Photoshop est plus facile / plus amusant que de faire du vrai travail.
la source
il peut bien y avoir un système que vous ne connaissez tout simplement pas.
Une entreprise pour laquelle j'ai travaillé a utilisé des noms de lauréats du prix Nobel pour tous leurs serveurs. Différents prix Nobel ont indiqué différentes catégories de serveurs.
Les serveurs de test peuvent être nommés d' après gagnants de mathématiques, les serveurs de base de données après gagnants de la littérature, les serveurs de messagerie après gagnants de la médecine, etc. , etc.
à quelqu'un pas familier avec la convention de nommage, les noms semblaient complètement aléatoires ( d' autant plus que la plupart des gens ne connaissent pas tous les centaines de lauréats du prix Nobel au cours des décennies).
J'ai utilisé un système similaire à la maison, nommant les ordinateurs d'après les chasseurs à réaction, les serveurs après les bombardiers et les volumes de disque après les volcans.
La même chose pourrait être faite avec des logiciels, nommer les versions de production d'après les arbres, les versions bêta après les fleurs, etc. etc.
la source