Creo que el uso de nombres en clave está bastante extendido. Nuestra empresa también los está utilizando.
Pero mi principal preocupación es que estos nombres generalmente no están documentados en ninguna parte. Y el significado se transmite de boca en boca. Y los nombres no tienen nada que ver con la función de la herramienta o entidad que se nombra.
Veo el patrón de que las máquinas de prueba internas llevan el nombre de las constelaciones, los servidores públicos se nombran después de los dioses griegos. Y los proyectos llevan nombres de lugares o el nombre de alguna estrella de cine o nombre de personaje elegido al azar. Pero no hay información directamente disponible del nombre si las máquinas son Windows o Linux; Servidores de 32 o 64 bits. O de qué se trata el proyecto.
Simplemente tengo un mal presentimiento cuando veo el mensaje de confirmación del VCS de que alguien acaba de ramificar el proyecto "Gandalf" o el proyecto "Callanish" o cualquier otro proyecto. Solo por la misma razón, generalmente no nombra sus funciones y variables de esa manera.
Propuse que deberíamos usar nombres más descriptivos, al menos para las nuevas entidades, pero enfrenté una oposición muy fuerte. Aparentemente, a todos en la organización, excepto a mí, les encanta nombrar cosas así.
Entonces, ¿por qué usamos nombres en código no descriptivos?
No me malinterpreten, no tengo problemas para nombrar versiones de programas e hitos, o tener un buen nombre de producto por razones de marketing. Pero todos los demás lugares me gustaría ver nombres descriptivos.
EDITAR:
Para darle un poco de contexto: Gandalf es un proyecto que porta el código de 64 bits. Callanish es el que lo transfiere a Android ... Prefiero llamar a la antigua sucursal 64bitporting y a la última androidporting. Tal vez un sufijo adjunto que denote la versión de destino que planeamos enviarlo. Para que todos sepan por nombre de qué se trata.
Los servidores en cuestión son imágenes de máquinas virtuales en las que probamos el producto ... Sin embargo, no conozco la máquina física en la que realmente se ejecuta. Entonces llamarlos windowsxp_32, windows7_64, debian_32 o solaris_64 está totalmente bien.
fuente
Respuestas:
No hacemos referencia a las personas por sus características, ya que lleva todo el día enumerarlas con suficiente detalle para no ser ambiguas y las características pueden cambiar. ¿Qué pasa si se cortan el pelo? En cambio les damos nombres. Además, las personas son mejores para recordar palabras que secuencias de símbolos aleatorios.
Descargo de responsabilidad: Esto va a contener algunas opiniones y cuentos anecdóticos debido a la pregunta.
En un lugar donde trabajé hace un par de años, todos nuestros servidores llevan el nombre de lunas y partes del cuerpo. "Rea", "Miranda", "pulmón", "riñón", etc.
Up high decidió, como usted, que todo esto era un poco tonto y deberíamos cambiarlos a nombres más "descriptivos" como "arc-sql-w-4" o "lon-web-lin-2". Esto se encontró con mucha oposición. Pero pasó. Cambiamos el nombre de todo.
Entonces, ¿qué salió mal?
Anteriormente, sabríamos desde la parte superior de nuestras cabezas qué máquinas eran las bases de datos principales y cuáles eran los esclavos porque podíamos recordar "cabeza" controlada por el "corazón" o que "Tarvos" era un servidor de aplicaciones para X. Lo que sea. Ahora teníamos que recordar una oscura pila de símbolos que parcialmente, pero no completamente, describían la máquina que estábamos buscando. Teníamos que saber a través de una tabla de búsqueda en nuestras cabezas que "lon-web-lin-1" era un servidor de aplicaciones para el producto A y "lon-web-lin-2" para el producto B.
Es similar a las razones por las que deberías usar contraseñas como FartDownT pantsForALivingDoYou? en lugar de 43gH5 # € 1. Las personas son buenas para recordar palabras, no pilas de basura al azar. Las palabras son símbolos que se refieren a cosas.
Otro problema (posiblemente más práctico) es que está vinculando sus nombres de DNS y servidor a sus funciones. Lo que significa que no puede cambiar la función sin cambiar el nombre. Para nosotros, esto también incluía la ubicación física y el sistema operativo. Lo cual es un dolor masivo en el culo.
Además, y este es el último punto. Los nombres son mucho más divertidos.
¿Qué pasa con los nombres de los proyectos?
Bueno, en lugar de "Proyecto Gandalf", ¿qué propones? ¿"Proyectar la función prototipo X y ver si podemos desarrollarlo en un producto"? ¿Qué pasa si el alcance del proyecto cambia, luego cambiamos el nombre del proyecto? Nuevamente, los nombres son símbolos abreviados que se refieren a cosas.
fuente
db3.todoapp
es más informativo si el servidor solo manejatodoapp
. Si el departamento de marketing decide llamar a la aplicación "Organizer Pro" y tiene otras 8 aplicaciones en el servidor, administrar los nombres puede ser bastante complicado.Nombrar cosas por sus propiedades es una idea fundamentalmente mala. La razón es que las propiedades son, por definición, fenómenos cambiables, mientras que la identidad de una cosa permanece igual incluso si se cambian las propiedades.
¿Alguien decide que el servidor de archivos debe migrarse a Linux? Si su nombre es "Apolo", eso no es un problema. Si el nombre hace referencia a "ventanas", entonces se volvería engañoso o tendría que cambiarse en todas partes a un gran costo o riesgo. ¿Estás presentando un nuevo formato de salida? ¡Por el amor de Dios, no lo llames 'newFormat'! Se va a ser sustituido eventualmente una vez más, y el formato aún más reciente necesitará un nombre aún más descriptiva para distinguirlo. Llámelo '3', para que luego pueda aumentarlo a '4', o 'oro' para que pueda actualizar a 'platino'.
(Una razón adicional es que los nombres compuestos de pepitas de información son muy feos. Nadie quiere trabajar en una computadora llamada "PC-Marketing-Windows7-143"; tomarán "Apollo" o incluso "Bacchus" sobre eso cualquier día, pero el punto principal es la división identidad / propiedad).
fuente
Hermes
entonces sí, es más reconocible quefunctionWithTenLinesOfCode
. Sinprint
embargo , personalmente lo llamaría .print_left_aligned_to_CRT_monitor()
Cathy()
. nota: He visto personalmente el código de producción con nombres de funciones y variables que citan las letras de Guns & Roses y soy culpable de escribir código de producción con nombres de variables y funciones que hacen referencia a Buffy.Hay 3 razones, en mi experiencia:
Cuando tiene que nombrar muchas cosas similares, puede ser difícil encontrar nombres descriptivos únicos para todas ellas. Las personas necesitan una forma única y breve de referirse a él, y somos mejores para usar nombres que para usar números (a menos que el número sea muy corto). Cuando le da un nombre, tiende a adquirir una personalidad en su mente, por lo que recordará que el servidor Gandalf es el que tiene el conector de alimentación escamoso mejor que SERWIN15AB23. También es menos probable que confundas dos de ellos con un error tipográfico.
El proceso de denominación puede ser divertido. Algunas compañías lo hacen con un voto. A otras personas les gusta inventar nombres únicos. Solo pregúntale a cualquier padre.
Para proyectos externos, generalmente es el marketing el que decide cuál es el nombre, y normalmente lo hacen justo antes de que se envíe. ¿Cuándo decidió Microsoft llamar al último sistema operativo "Windows 10"? Dudo que siempre se llamara así. El proyecto podría estar en desarrollo durante mucho tiempo antes de eso, y en algunos casos querrás ofuscarlo para que las personas fuera de la empresa no sepan de qué estás hablando.
fuente
La denominación descriptiva es difícil ™, es mucho más fácil si ya tiene un tema que viene automáticamente con una lista de palabras que puede usar.
Cuando usted tiene múltiples del mismo objeto nombrarlos
foo1.6
,foo1.2
etc. pronto se le va confundiendo / propenso a errores. Por ejemplo, cuando necesite ejecutar su pruebaVirgo
, notará rápidamente el error si está en funcionamientoCancer
.También se convierte en una reunión entretenida cuando se implementan las convenciones de nomenclatura y se toma la decisión de basar los nombres de las salas de conferencias según los géneros musicales y el nombre de la cafetería
Salsa
.fuente
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.
Muy cierto. Pero el hecho de que sea más fácil no significa que sea bueno a largo plazo. Lo que estás diciendo no es diferente a no hacer un diseño API adecuado, porque es mucho más fácil simplemente producir funcionalidad.Esto puede estar relacionado con un contexto alto o una cultura de contexto bajo . Cada empresa, organización o equipo tiene su propia cultura. Cultura de contexto alto o bajo significa cuánta información le gusta a una cultura relacionar explícitamente y cuánta gente se espera que tome del contexto.
Nombrar todos los servicios con nombres de referencias culturales proporciona cierta flexibilidad, pero también carece de carácter explícito. Tiene que haber un boca a boca o "conocimiento tribal" que complemente los nombres, es decir, el contexto del servicio. He visto situaciones en las que, por ejemplo, está el servidor "fizzbuzz" o el servicio "marcopolo" en el que nadie sabe lo que hacen, pero obtienen tráfico, por lo que deben hacer algo.
Soy una persona de bajo contexto, por lo que tiendo a elegir nombres simples y explícitos que proporcionen contexto sobre el propósito de un servidor o servicio. También escribo "código autodocumentado" donde tengo cuidado al nombrar mi código para hacerlo más legible.
Pero actualmente estoy trabajando en una tienda de alto contexto donde todos los servicios llevan el nombre de Transfomers. Suspiro. Al menos usan los nombres consistentemente.
Por lo tanto, parece más un valor cultural, pero las prácticas técnicas se adaptarán a las preferencias culturales.
El contexto alto también puede ser más divertido, y eso tiene cierto valor.
fuente
Una razón para los nombres en clave es la ofuscación. Si hace que el nombre de un proyecto no tenga sentido, puede hablarlo en público sin que nadie más entienda lo que está discutiendo.
Del mismo modo, si le da a sus servidores nombres sin sentido, nadie, excepto los usuarios autorizados, tendrá idea de lo que hay en ellos.
fuente
La pregunta importante es: ¿qué es descriptivo? Las otras respuestas han hecho un gran trabajo ilustrando lo que no es descriptivo.
Establezcamos que la descriptiva proviene de llamar a las cosas por su rol , su propósito. Por lo que hacen . Por ejemplo, está bastante claro lo que hace un "cortador". Ahora podría ser un hacha, un láser o un cuchillo. No importa tanto Y un láser también podría ser un "puntero", un hacha también puede ser un "decorador" y un cuchillo también puede ser un "perforador".
Entonces, como otros han señalado, la relación entre las propiedades de algo y la tarea que cumple es relativamente laxa. Por lo tanto, el SO que forma parte del nombre del servidor no es descriptivo , sino que distrae del verdadero propósito.
A menos que sea su trabajo trabajar en cómo el componente
DoesX
logra X, no es asunto suyo. Si es tu trabajo, entonces te enfrentas inmediatamente de todos modos.Como señaló rachet freak, a veces es difícil encontrar nombres descriptivos. Pero la mayoría de las veces, eso es una señal de no haber entendido lo que hacen las cosas, que debes nombrar. Antes de tener esa comprensión, probablemente no debería preocuparse por cómo hace lo que no sabe;)
fuente
http-blog-db-failover
para una máquina que aloja una base de datos de conmutación por error de un sitio web que aloja blogs; mudarse de Linux a Windows o de MongoDB a CouchDB no afectará el nombre, ni las decisiones de marketing. )La primera razón es que puede ser breve y memorable. Si piensa cuántas veces va a decir o escribir el nombre del proyecto, ahorrará una cantidad considerable de tiempo si hay un nombre breve que todos conocen y entienden.
La segunda razón es que crea camaradería. Si el equipo elige el nombre, puede elegir uno que les guste a todos. Es sutil, pero aumenta la moral del equipo cuando estás trabajando en un proyecto llamado Viper o Gimley o Boba o Bugatti en lugar de un proyecto llamado 'Actualizaciones de contabilidad Q3'. Tenía un amigo que trabajaba en un equipo con un grupo de entusiastas del automóvil. Su ritual de inicio favorito del proyecto fue elegir qué automóvil usarían como nombre clave del proyecto.
fuente
Siempre he pensado que esto es algo que se hace principalmente porque divierte a la gente. Los medios condicionan a las personas para que otorguen valor a merodear en la oscuridad en lugar de operar a la luz del día. A los 5 años tenemos el "Agente Especial Oso"; a los 15 años es James Bond. El secreto otorga un aire de importancia a las actividades mundanas de las personas (por ejemplo, programar una computadora).
Del mismo modo, alguien creó un logotipo para "Longhorn" cuando era un nombre en clave de Microsoft ( http://en.wikipedia.org/wiki/File:Windows_Longhorn_logo.svg ). ¿Por qué alguien haría un logotipo para un nombre en clave que no pretende ser realmente parte de ningún esfuerzo de marketing? Una vez más, las personas hacen este tipo de cosas porque les divierte. Jugar en Photoshop es más fácil / más divertido que realmente hacer un trabajo real.
fuente
puede haber un sistema que simplemente no conoces.
Una empresa para la que trabajé utilizaba nombres de ganadores del Premio Nobel para todos sus servidores. Diferentes premios Nobel indicaron diferentes categorías de servidores.
Servidores de prueba podrían llevar el nombre de los ganadores de matemáticas, servidores de base de datos después de ganadores literatura, servidores de correo después de ganadores de la medicina, etc., etc.
Para alguien no familiarizado con la convención de nomenclatura, los nombres parecían completamente al azar (sobre todo porque la mayoría de la gente no conoce todos aquellos cientos de ganadores del Premio Nobel a lo largo de las décadas).
He usado un sistema similar en casa, nombrando computadoras después de los aviones de combate, servidores después de los bombarderos y volúmenes de disco después de los volcanes.
Lo mismo podría hacerse con piezas de software, nombres de versiones de producción después de árboles, versiones beta después de flores, etc. etc.
fuente