Una práctica algo común en algunos proyectos de software es el nombrar con nombres propios sistemas internos, que no son parte de la interfaz pública y sólo son visibles para el equipo. Recuerdo que esta práctica me frustraba mucho cuando entré a mi primer trabajo, porque hacía que saber qué era cada cosa fuera mucho más difícil. Me pasaba el día preguntándome por qué alguien en su sano juicio llamaría a su sistema

en vez de “agregador de proveedores de información”. Y la verdad es que hasta ahora no había encontrado ningún argumento de peso a favor de esta práctica, a la que desde luego le veo muchos en contra. Pero desde hoy, por fin, tengo al menos un argumento a favor de nombrar sistemas internos. Puede facilitar algunas tomas de decisiones a la hora de reutilizar código a largo plazo.

Como explico en

, reusar código es difícil porque intentar reusar un sistema que no resuelve exactamente el mismo problema que uno tiene puede conllevar más trabajo que escribir una nueva solución específica para la nueva situación. Y toda ayuda a la hora de tomar una decisión correcta sobre si reusar un sistema ya existente o escribir uno nuevo es beneficiosa. ¿De qué forma pueden ayudar pues estos nombres propios a tomar correctamente esa decisión?

Necesitamos formas breves de referirnos a los sistemas que programamos, para poder referirnos a ellos en conversaciones del día a día. Nadie va a referirse a una parte de su código como “sistema de tal en esta situación y bajo estas limitaciones”. Nombres como “sistema de gráficos” o “sistema de misiones” funcionan muy bien durante el desarrollo de un proyecto. Lo normal es que un programa tenga un solo sistema de X, así que la antonomasia funciona perfectamente. Es además muy fácil saber de qué estamos hablando. El nombre se asocia perfectamente a la parte del programa que hace eso. Esta forma de nombrar deja de funcionar tan bien cuando entra en juego el reutilizar o compartir estos sistemas a lo largo de varios proyectos. Porque ahora ya no hay un solo sistema de X. O al menos no hay un solo sistema de X posible.

Supongamos que una empresa ha hecho un videojuego que tiene la estructura de niveles de un

, y ha hecho un sistema para gestionar qué niveles tiene el jugador disponible en cada momento y cómo se desbloquean niveles nuevos al completar otros. Como el juego va sobre un agente secreto que se infiltra en sitios y los niveles son las diferentes misiones que le encomiendan, coloquialmente se le llama a este sistema dentro del desarrollo el “sistema de misiones”. Ahora supongamos que otro equipo en esta misma empresa va a empezar un nuevo proyecto. Este nuevo proyecto es un juego de mundo abierto con decenas de hilos que el jugador puede poner en marcha e ir completando mediante la interacción con diferentes personajes y partes del mundo. Podemos pensar en un

, un

, un

… A estos hilos el equipo los llama misiones, y está hablando ahora sobre hacer un “sistema de misiones” para gestionar esta información. Han oído hablar de que el equipo de al lado ya ha hecho un “sistema de misiones” para su juego de agentes secretos, así que a lo mejor lo pueden reusar. Desde luego que les ahorraría mucho tiempo. Pero lo cierto es que un juego con la estructura de un

y un juego con la estructura de un

se parecen lo que un huevo a una castaña, y el “sistema de misiones” para cada uno de estos juegos tiene que ser completamente distinto. Por desgracia, llamarlos igual constantemente en el día a día hace que la tarea de explicar que no se puede reusar este sistema porque el problema no tiene nada que ver sea una constante batalla cuesta arriba.

Como explico en mi anterior texto, para reusar un sistema de un proyecto anterior hay que entender muy bien el contexto concreto en el que se escribió, sus objetivos y sus limitaciones. Cuando nombramos llamando a algo sistema de X, estamos eliminando todo ese contexto, y dando al sistema un nombre mucho más abstracto que su funcionalidad real, lo que puede inducir a error y hacer pensar a otras personas que el sistema puede hacer más de lo que hace, o cosas distintas de las que hace. También estaría convirtiendo a este sistema de X en el sistema de X por antonomasia para toda la empresa. En el futuro, cada juego que tenga algo llamado misiones va a tener que perder tiempo entendiendo que ya existe algo llamado “sistema de misiones” e intentando ver cómo encajan las reglas de su juego en el marco de este sistema que ya está hecho. Sería conveniente una forma de nombrar a los sistemas que no perdiera todo este contexto valioso.

Y ahí es donde entran en juego los nombres propios. Imaginemos esta vez que el primer equipo, el del juego de espías, no ha llamado al código que gestiona qué misiones están desbloqueadas “sistema de misiones”, sino que lo ha llamado, yo qué sé,

. Ahora podemos tener una discusión sobre si

sí o

no. ¿Usamos

o escribimos otro sistema que sea más adecuado para el juego que estamos haciendo? Es más, si el otro equipo decide con razón que

no les sirve para su juego, pueden también generalizar su sistema y llamarlo, qué sé yo,

, y a partir de ahora futuros proyectos pueden elegir si quieren usar

o

o escribir uno nuevo. Se puede tener discusiones sobre las ventajas y desventajas de cada uno de ellos, las situaciones donde pueden ser usados o no, problemas que ha habido en el pasado por decidir mal… Dar un nombre propio arbitrario al sistema hace que al referirnos a él cada día en conversación nos estemos refiriendo a un sistema concreto con un contexto concreto y unas limitaciones concretas. Que tiene pros, contras, alternativas. Los nombres arbitrarios no inducen a error. En el peor de los casos no dicen nada. Por supuesto, es buena idea tener una buena documentación de qué es cada nombre, para no hacer la vida imposible a gente nueva entrando al equipo.

En cierta medida ya funcionamos así a la hora de usar software de terceros. Un juego puede debatir sobre si usa

,

,

o escribe su propio motor. Al elegir base de datos hablamos de si usar

,

,

… Cada una tiene ventajas e inconvenientes, y poder darles un nombre nos permite tener estas conversaciones. Si todos se llamaran

™️ o

™️ sería imposible tener esta conversación.

¿Pienso ahora que dar nombres propios a sistemas internos es buena idea? La verdad es que no. Creo que el coste cognitivo extra que tiene para la gente nueva es un coste difícil de ignorar. Pero es que no es sólo para la gente nueva. Simplemente cambiar de equipo o tener que trabajar en un área nueva del proyecto implica tener que aprender toda una pila de términos nuevos arbitrarios y difícilmente asociables a su significado salvo mediante memorización. Además, el listón de calidad que impone a la documentación para poder funcionar es muy alto para la mayoría de equipos. Cada uno de estos palabros mágicos tiene que ser fácil de buscar en un momento, porque si no intentar trabajar en nada nuevo se vuelve una tarea farragosa y frustrante a más no poder. Pero al menos ahora tengo un argumento serio a favor de esta práctica tan molesta. Hasta ahora no tenía ninguno.