Hola, soy Cecilia y esta será una miniserie con algunas de las últimas lecciones que he aprendido en estos últimos meses como líder de un equipo de desarrolladores frontend.

El primer tema con el que quiero arrancar es como reducir el código duplicado en tus proyectos de frontend. Pongamos un ejemplo, digamos que te han solicitado desarrollar una característica nueva en tu proyecto, leer y guardar un token de autenticación en el store de tu aplicación. Es la primera vez que creas esta funcionalidad, así que lo haces. Meses después, te asignan a un proyecto nuevo y te piden nuevamente que leas y guardes un token de autenticación en el store para esta aplicación y recuerdas “Hey! Yo ya he hecho esto antes”. Así que decides copiar y pegar el código que ya habías creado.

Pasan los meses de nuevo y ¡qué crees! Adivinaste, un tercer proyecto aparece y necesita también el famoso token de autenticación. ¿Qué harás esta ocasión? ¿Volverás a copiar y pegar el código de nuevo? Suena tentador, lo sé. Es lo más fácil y sencillo de hacer, pero esta solución rápida nos deja con los siguientes problemas:

• ¿Qué pasa si llegan 5 proyectos nuevos? ¿Seguiremos copiando N veces más?
• ¿Y sí además de leer y guardar el token ahora se necesita actualizar al momento de expirar? ¿Tendré que ir manualmente a cada proyecto a extender esta funcionalidad?
• ¿O qué sucede si mi código tiene un error o encontré una manera más eficiente de manejar el token y necesito refactorizar? Nuevamente, tengo que ir a modificar el código en N proyectos diferentes

Como ves, no siempre lo más sencillo es más conveniente a largo plazo. Una cualidad que diferencia a un desarrollador con poca experiencia a uno más experimentado es la capacidad de adelantarse y planear a futuro como sus desarrollos puede expandirse, el famoso “ver a futuro” que has escuchado mencionar. Y este es un buen ejemplo, cuando comienzas a detectar que una funcionalidad empieza a repetirse o necesitar en más de un proyecto, seguramente estás ante un candidato de código a encapsular y empaquetar.

¿Has escuchado hablar del concepto DRY? Don't Repeat Yourself (No te repitas!) nos recuerda que cada comportamiento repetible en el código debe estar aislado (por ejemplo, separado en una función) para su reutilización. Este es un principio de diseño de software muy famoso y que si no habías escuchado hablar de él, te invito a investigar más acerca de este y otros más.

Pero volvamos al ejemplo del token. Ya tenemos identificado el fragmento de código que necesitamos separar, ahora que sigue? Mi consejo sería crear un pequeño módulo npm que solo contenga la lógica necesaria para manipular el token. Recuerda dejar este código lo más aislado de reglas de negocio de los proyectos o detalles muy particulares de los mismos, o en otras palabras: que solo tenga un solo objetivo, en este caso manipular el token, ¡no más!. (Otro principio que te invito a investigar relacionado a esto: SRP o Single Responsibility Principle)
Ya que has logrado crear tu nuevo módulo npm, ahora habrá que publicarlo en algún repositorio de módulos, puede ser en npm.js, github.com o alguno privado (sabías que GitLab tiene opción para esto? Si quisiera aprender como, déjame un comentario para saber que te interesa un artículo explicando más a detalle cómo funciona).

Por último, la parte que más me emociona, borrar el código que ya hemos migrado y reemplazarlo instalando nuestro nuevo módulo npm (Esto me hizo recordar una de mis frases favoritas; “Los buenos programadores escriben un buen código. Los grandes programadores no escriben código. Los programadores Zen eliminan el código”) La funcionalidad debe seguir trabajando como si nada hubiese cambiado, los usuarios no notarán el cambio. Pero tu yo del futuro y otros programadores si lo harán, y verán los siguientes beneficios:

• Desarrollos más veloces cuando un nuevo proyecto necesite esta funcionalidad.
• Propagación de fixes de bugs encontrados o extensión de funcionalidades más veloces, ya que ahora se podrá mantener el módulo por separado y solo habrá que actualizar la versión de la librería en los proyectos donde se mande llamar.
• Reducción de código duplicado y estandarización de estrategias para resolver un mismo problema a lo largo de los proyectos de tu empresa

Como ves, los beneficios son muy atractivos y beneficios a largo plazo. ¿Has pensado en alguna funcionalidad de alguno de tus proyectos que podrías encapsular y reducir el código duplicado en tu trabajo? Platícame en los comentarios

Gracias por leer, nos vemos en la próxima!