Clean Code y MuleSoft: naming

Allá por el 2009, Robert C. Martín, también conocido por Uncle Bob, publicó el que para muchos se convertiría el libro de cabecera de todo programador, el Clean Code. En sus páginas, hay multitud de recomendaciones para crear lo que podemos considerar un código limpio, y aunque pueden existir tantas definiciones de lo que es un código limpio como personas que tratan de definirlo, para estas líneas nos quedaremos con una sencilla: código entendible y fácil de leer.

Si bien el desarrollo en MuleSoft, hablando sobre todo del ESB , no sigue una estructura similar al que hace referencia este libro, que se enfoca sobre todo en el paradigma de orientación a objetos, vamos a ver qué enseñanzas podemos extraer para desarrollador código limpio.

Nos centraremos sobre todo en la parte de código entendible, porque ya sabemos todos que en realidad, cualquier desarrollador pasa más tiempo leyendo código que escribiéndolo. Y además, la regla de oro de “escribe código como si más adelante un psicópata fuera a intentar leerlo” está bien, pero no nos dice cómo hacerlo.

Puntos a tener en cuenta

Repasaremos los puntos que el segundo capítulo del libro, Nombres con sentido, nos lista para ayudarnos, parándonos en aquellos que más sentido tengan en el caso de desarrollos sobre MuleSoft.

Merece la pena mencionar que la mayoría de los puntos son fácilmente aplicables a código Dataweave, pero también en los flujos más visuales querremos usarlos.

NOTA: Clean Code se caracteriza por no ser el libro técnico mejor traducido de la historia. Si ves que el título de algún punto no es especialmente descriptivo del contenido, es porque he optado por usar los textos tal cual de la versión en español del libro.

Usar nombres que revelen las intenciones

Este punto es bastante descriptivo, así que optaremos por recoger literalmente lo que contiene:

Es fácil afirmar que los nombres deben revelar nuestras intenciones. Lo que queremos recalcar es la importancia de hacerlo. Elegir nombres correctos lleva tiempo pero también ahorra trabajo. Por ello, preste atención a los nombres y cámbielos cuando encuentre otros mejores. Todo el que lea su código lo agradecerá. El nombre de una variable, función o clase [en nuestro caso de MuleSoft, podemos hablar de nombres de variables funciones, flujos, sub-flujos, conectores/nodos y archivos y paquetes] debe responder a una serie de cuestiones básicas. Debe indicar por qué existe, qué hace y cómo se usa. Si un nombre requiere un comentario, significa que no revela su cometido. […]

Evitar la desinformación

Esto parece fácil de entender y lógico, pero a veces caemos en este error. Usamos nombres de variable, como pudiera ser aix por ejemplo, que no dicen nada de por sí. Usamos cosas como accountList para variables que no contienen una lista, o incluso nodos llamados request cuando son una transformación, tal vez heredado de un cambio pasado, pero al que no prestamos atención al naming.

Usar nombres que se puedan pronunciar

Como humanos, gran parte de nuestro cerebro se dedica a las “palabras”, por lo que sería malgastar el tiempo usando unas que no podamos pronunciar. Gran parte de esta recomendación viene de simplificar el momento en que tengas que explicar algo sin parecer tonto.

Usar nombres que se puedan buscar

Nombres de una letra y constantes numéricas son difíciles de localizar en el texto. Piensa en el número de coincidencias tendrás si buscas algo llamado “e”.

Evitar codificaciones

Suficientes codificaciones tenemos ya como para tener que añadir y aprender nuevas. Es una carga mental innecesaria, así que simplifiquemos.

Prefijos de miembros

Cosas como añadir “m_” o similares al principio de una variable (o flujo, o lo que sea), no son necesarias. Los desarrolladores tienden a ignorar rápidamente los prefijos, así que ¿para qué gastar ese esfuerzo?

Evitar asignaciones mentales

Esto es algo parecido al punto anterior de evitar codificaciones. Debemos evitar que un lector tenga que hacer una traducción mental de unos nombres en otros que ya conoce. Aquí podemos usar una regla que debería ser máxima: elegir nombres que sean fáciles y entendibles para los lectores.

Nombres de clases

El libro habla de clases, pero lo podemos extender a otros elementos como pueden ser flujos, conectores, nodos,…Evitar palabras genéricas y verbos.

No se exceda con el atractivo

Volvemos a lo ya hablado, Puede que seas el programador más creativo del mundo, el más gracioso y capaz de crear chistes de todo y hacerlo divertido. Por favor, no: opta por nombres entendibles y auto descriptivos. ¿Alguien es capaz de decir qué hace algo llamado “HolyHandGranade”? (A menos que estés creando un video juego bélico :p )

Una palabra por concepto

Esto es fácil de entender, y trata sobre ser consistente. Es un ejemplo claro decir que no usemos “fetch”, “retrieve”, “get”, como acciones equivalentes en distintos lugares. Elige uno y sé consistente.

No haga juego de palabras

Parecido a lo de antes. No usemos la misma palabra con dos fines distintos. y de nuevo, usemos la regla de oro: hagamos nuestro código entendible.

Usar nombres de dominios de soluciones

Quien va a leer el código, será otro desarrollador y entenderá términos informáticos, algoritmos, patrones,... No uses otros nombres cuando tus lectores conocen y entenderán otros. Usar nombres de dominios de problemas Este punto viene juntito al anterior. Cuando no exista un término de programación para el concepto que quieres nombrar, usa un nombre del dominio del problema que estás solucionando.

Conclusión

Hemos hablado de bastantes puntos, y podríamos hacerlo de bastantes más, dando algunas recomendaciones; algunas tendrán mucho sentido para ti, otras no verás ocasión para aplicar, pero podemos hacer un rápido resumen usando la regla de oro que hemos mencionado. Tu código/proyecto se va a leer durante bastante más tiempo del que se pasa escribiendo y es por ello que, como buenos profesionales, debemos asegurarnos que esas lecturas sean fáciles, que se entiendan rápidamente sin necesitar más conocimiento extra del estrictamente necesario. Y esta regla la podrás aplicar a variables, métodos, clases, nodos, flujos, sub-flujos, conectores, archivos ,…. en definitiva, cualquier cosa que pueda ser nombrada.

Tags

He leído y acepto la política de privacidad
Acepto recibir emails sobre actividades de recruiting NTT DATA