02 October 2011

Una rosa con otro nombre puede terminar como un repollo

Tiempo atrás escuche algunas personas decidir que necesitan más capas en su arquitectura. Estaban en lo correcto, como es el caso; pero mirando un poco más atrás. Ellos intentaban crear un framework que contenía lógica de negocio. Pero en lugar de centrarse en resolver los problemas concretos empezaron con la idea de que querían un framework que envolviera la DB y produjera objetos. Y que se debe usar un ORM, y mensajes, y webservices y todo tipo de cosas interesantes.

Desafortunadamente, el no tener claro exactamente qué tipo de cosas interesantes podría hacer, llevo hacia una pequeña competición para sugerir un nombre. Y este es el punto, en el cual puede empezar a reconocer que usted tiene un problema: Si no sabe qué nombre poner, usted no sabe lo que es, si usted no sabe lo que es, no debería empezar a escribir código.

En este caso en particular, un vistazo rápido por el historial del control de versiones del código, puso en manifiesto la gravedad del problema. Por su puesto, había muchas implementaciones vacías de interfaces! Y lo realmente divertido es que habían cambiado de nombre tres veces sin haber escrito código real. Cuando empezaron le llamaron ClientAPI – el “client” se refiere a los clientes de la empresa, no cliente como en “client-server” – la versión final fue llamada ClientBusinessObjects. Un gran nombre: Vago, amplio y engañoso.

Está claro, un nombre es solo un puntero. Una vez que todos los involucrados saben que el nombre es solo un nombre y no una metáfora de diseño, entonces todo puede pasar. Sin embargo, si no hay acuerdo en un nombre lo suficientemente específico para saber cuando está mal, entonces podrá tener alguna dificultad, incluso para empezar. El diseño de un producto tiene que intentar cumplir con las intenciones – Ej.: Rápido, barato, flexible – y los nombres deben transmitir o reflejar las intenciones.

Si no se puede poner un nombre, no se puede escribir. Si se cambia de nombre tres veces, entonces se debe parar hasta que tenga claro que es lo que va a construir.

Autor Sam Gardiner

Versión original : A rose by any other name will end up as a cabbage


Algunas veces, en alguna que otra organización, grupo de personas o comunidad, se suelen identificar a la misma cosa (idea, concepto, aplicación, programa...) con distintos nombres, que, dependiendo de su audiencia se le puede identificar con un significado o proposito distinto, y en ese punto es donde pueden empezar muchos problemas.

Lo ideal en estos casos es identificar a todas las personas relacionadas, juntarlas y alinearlas (esclarecer los objetivos de la aplicación, sus usos, normalizar los términos a utilizar...) para que, entre otras cosas, todos hablen el mismo idioma, ese, es un buen punto de inicio para el éxito de cada aplicación.

Emmerson

-FIN -

No comments: