Mas que un nombre

Hace un par de semanas tuve un pequeño debate con el DBA del lugar donde trabajo, sobre el uso de convenciones a la hora de usar Nhibernate en un proyecto nuevo.

Cuando me pidió un ejemplo de como se llamarían las tablas y las columnas del nuevo sistema, le mostré los resultados, a los 2 mins de ver los nombres de las tablas resultantes después de crear el esquema con Nhibernate, la cara de asombro poco a poco fue tornándose en una cara de angustia, estupor y finalmente contrariedad, y a los pocos segundos dijo:

NOOOOOOOOOO!!!! Eso esta mal, las tablas y columnas no pueden nombrarse así, para eso esta el estándar!!!, ya hay un documento donde se explican los mnemotécnicos a usar.... esto esta muy mal!!!.

Primero hablamos acerca del estándar al que hacia referencia, el cual había sido utilizado en un proyecto legacy que se había construido hace casi 5 años y que lamentablemente en ese proyecto se había descuidado el tema sobre las convenciones de programación, nombres, etc...

Y que en el nuevo proyecto habíamos decidido aplicar clean code en el sentido completo de lo que ello implica.

A todo esto indico que, estaba mal porque no podía aplicarse a tablas y columnas ya que no eran programas y que los mnemotécnicos eran más que claros,

a esto le replique que leyera tal cual los nombres de las tablas del anterior sistema, para lo cual el leyó usando ya su previo conocimiento del dominio del sistema, por lo que no leyó si no interpreto los nombres, le replique que eso estaba mal y le dije que si una tabla se llama rcmcred se leía ere-ce-eme-ce-ere-e-de (exagere un poco) pero quería demostrar mi punto de vista... el soltó una risa burlona y dijo que la leyera como debería ser es decir erecemecred... le dije que no era así.... luego le mencione que el nombre podría ser "deudoresregistrocrediticio" y me dijo que muy largo yo le dije que podría ser registrocrediticio a lo que el replico, ya ves ya tiene 2 nombres posibles, en cambio con los mnemotécnicos solo tendría uno y estaría en el diccionario de datos.....

Y le dije, bueno no tiene dos nombres por el momento tiene 2 posibles nombres aun no la habíamos bautizado =D, entonces él dijo: pero entonces el nombre podría ser toda la descripción que esta en el diccionario de datos y con ello estaría bien...

le replique que eso era un extremo y que los extremos no son buenos, y además que una ventaja de nombrarlo RegistroCrediticio, ya por si mismo daría una noción de lo que es según el contexto (dominio) y no tendría que hacer un select adicional para buscar en el diccionario de datos para poder consultar la descripción de la tabla, a lo que agregue que lo mismo ocurre con los campos no tiene ningún sentido poner c_codper para guardar el código de la persona debería ser "codigopersona" o "id", además c_codper es un campo con solo números y ceros a la izquierda que tal vez después cambiemos el tipo por temas de negocio y la c_ no tenga nada que ver con el tipo de dato ya que esa es la intención de pre-fijarla c_, y le hice ver que lo mismo ocurría las variables, métodos, clases etc...

El asintió pero dijo "entonces para que estaría el diccionario de datos si la descripción ya no seria necesaria?"

Le dije pues que para información complementaria u otro fin que permitan un mejor entendimiento si no conoces muy bien el dominio del sistema.

Y me dijo NOOOO!!!! el diccionario tiene su función, además las buenas practicas (según un fabricante muy renombrado en el mundo de las BD), menciona que es una buena practica el uso de mnemotécnicos, y hay documentos que sustentan lo que digo, y bla y bla y bla... todo ello orientado a la base de datos que usamos aquí.

le comente además que si hacia una búsqueda usando el buscador de objetos o una búsqueda de texto dentro de los objetos del diccionario de datos, consultar seria sencillo porque sabría el significado de los resultados de la búsqueda con solo leerlos, sin necesidad de ir al diccionario de datos.

a lo que finalmente termino la conversación diciendo "yo no estoy de acuerdo. y quien debería definir esto es el gerente de TI, pero YO NO ESTOY DE ACUERDO... y solo aceptare eso si el gerente de TI me dice que lo haga, debe usarse el diccionario de datos".

a lo que quiero llegar es que un nombre bien escrito, auto-descriptivo, ya sea de una variable, método, clase, interfaz, archivo, tabla, campo, esquema, librería, namespace, test, etc... permite que el Código sea legible

Código legible no necesita comentarios explicativos, es entendible por si mismo.

Código legible es mas fácil de entender por ende mantener PERO es uno de los atributos que ayudan al mantenimiento hay muchos mas, de los cuales hablaremos en este blog.

Código legible parte de la documentación, complementando a los test, historias de usuario, etc.

con ello mejora:

la calidad del ambiente de trabajo, no tienes que perder horas de horas tratando de Descifrar el código, vas de frente a la vena ;-)

el código es leído y entendido por todo el equipo

incluso para el nuevo staff la transición es mucho más sencilla

por tanto mi recomendación es que piensen en lo nombres que le ponen a sus variables, clases, test, namespaces, métodos, etc...

porque los nombres son importantes, y el nombre que les den deben estar dentro del contexto de la solución que están desarrollando y su significado solo trasciende hasta esos límites

el nombre debe ser un elemento diferenciador entre elementos dentro de mismo ámbito.

no hay una regla general para esto y tampoco mi intención es dar un estándar, el equipo debe ver la forma de como ese estándar, esas convenciones emerjan.

así que piensa en un nombre ;-) no lo tomes a la ligera...