¿Tienes que cambiar de lenguaje y framework y no sabes cómo afrontarlo? Yo, suelo balancear entre distintos frameworks y tecnología, y con el tiempo he ido aprendiendo que cosas me funcionan, o cómo afrontar estos cambios. En este artículo te cuento unos cuantos trucos que a mí me ayudan a sobrellevar la curva de entrada de un proyecto nuevo con tecnología nueva. Espero que alguno de ellos te sirva de ayuda, y que veas que a parte de ser posible, hay formas de conseguir que nuestra salud mental no se sienta perjudicada en el camino.
El aumento del número de frameworks front-end durante los últimos años ha traído muchas consecuencias a nuestro día a día. Algunas son maravillosas, como el poder elegir entre una gran variedad cual es el más útil para nuestro proyecto en concreto. Pero también trae consigo, que sea habitual cambiar de uno a otro con cierta frecuencia. Esta última parte conlleva un período de adaptación y puede que muchas personas, tanto recién llegadas al sector como con muchos años de experiencia en un lenguaje determinado, lo afronten con nerviosismo o agobio.
Este último año laboral, he estado trabajando con diferentes lenguajes y/o frameworks: C#, Angular, Xamarín, Vue y Node. Además, en mi tiempo libre he probado Deno y también he estado con Javascript of Things, ESP32 y Arduino. No considero que tenga un nivel avanzado en muchos de ellos, de hecho, en alguno soy tremendamente principiante. Pero lo que, si he aprendido durante este periplo, son una serie de trucos para tratar que la curva de entrada a un proyecto con un nuevo framework me sea menos dura. Y eso, es lo que vengo a compartir contigo.
Así que comenzamos.
Documentación técnica y formación.
El primer punto que abordo es tratar de conocer el lenguaje o framework con el que voy a comenzar a trabajar. Lo ideal sería tener tiempo para leerse la documentación técnica oficial y hacerse algún curso online, pero en la realidad muchas veces esto no es posible. Así que tengo un camino corto, en mi caso particular suelo apuntarlo todo en formato analógico y tengo mis libretas mágicas.
Te detallo aquí los imprescindibles que yo busco y me apunto de forma muy esquemática, para tener siempre a mano:
- Gestión del ciclo de vida y de los eventos.
- Estructura básica de un componente
- Sintaxis de las estructuras condicionales y el bindeo de datos.
- Cómo se pueden comunicar dos componentes hermanos o un componente hijo con su componente padre
- Cómo añado clases condicionales al HTML
- Cómo valido un formulario
- Cómo gestiono el enrutamiento.
Si es un proyecto que no se empieza de cero: abrir y ejecutar el proyecto
Esta parte es una de las que siempre me da problemas. No sé por qué, pero siempre se me olvida algún paso o no tengo alguna dependencia instalada. Este proceso de conseguir ejecutar el código me permite comprender como está configurado el proyecto y su funcionamiento más básico.
Una vez arrancado realizo las siguientes acciones, que puedo hacerlas en más o menos profundidad dependiendo del tiempo del que disponga.
- Analizar la arquitectura del proyecto. Me hago una idea de donde están las vistas, los componentes, los servicios, los recursos, las pruebas…
- Tomar la primera pantalla y depurarla gracias a las herramientas del navegador, para así hacerme una idea de todas aquellas llamadas que a simple vista igual ignoré. También me sirve para ver cómo se están tomando y modificando los datos.
- Tratar de modificar una parte de una de las pantallas, si tengo poco tiempo puede ser simplemente cambiar el color y el texto de una label. Con esto consigo situarme bien en la estructura de archivos y ser capaz de orientarme fácilmente a través del código ya hecho. De paso, si el proyecto tiene test (ya sé que debería, pero no siempre es así), ver que no he roto nada.
- Trato de crear una nueva pantalla o apartado nuevo con poco contenido, para ver que soy capaz de ello. Esto parecerá una tontería, pero me da una tranquilidad y seguridad en mí misma que voy a necesitar a lo largo del proyecto.
- Pedir documentación sobre negocio, o si no la hay, si algún compañero puede explicarme un poco en que consiste la lógica interna de la aplicación, que quiere el cliente, que le suele gustar, que cosas normalmente manda cambiar… Vamos, tener un poco de historia y contexto del funcionamiento general.
Si el proyecto empieza de cero.
- Tratar de leer la documentación o al menos de analizar los requerimientos con lupa, si el lenguaje o framework es nuevo, el arranque del proyecto será más complejo.
- Definir muy bien mi rol, aunque sea para mí misma mentalmente. Esto no quiere decir que no trate de echar una mano en cualquier cosa que me pidan, pero me ayudará a tratar de no autoexigirme más de lo que debería. Y me explico, si yo tengo que desarrollar un requerimiento y la información que tengo es “x”, puedo preguntar para confirmar ciertos puntos. Pero si luego al acabarlo, se cambia de idea o resulta que debía tenerse en cuenta “y”, no es mi culpa. Y esto es algo muy importante, saber gestionar los fracasos y saber que a veces, no es nuestra culpa y que cuando la es, lo mejor es reconocerlos, apuntarlos y tratar de evitarlos a un futuro.
- Hablar mucho con mis compañeras y compañeros, pero mucho, mucho, mucho. Es importante para mí, el tratar de crear una estructura común, analizar con otras personas los requerimientos cuando son complejos y tratar de ver diferentes puntos de vista. Al final, esto es un trabajo en equipo.
- Tratar de crear una pantalla ejemplo, igual que en el caso anterior que el proyecto ya estaba inicializado para tener la estructura básica en mente.
Durante el proyecto
Pues durante el proyecto, mi libreta mágica es mi guía. No sólo porque la consulto habitualmente, sino porque cuando me atasco mucho con algo, o alguna otra persona del equipo me sugiere una mejora, me lo anoto. Al final es como un símil de diario, pero contiene información muy importante para mí. Este ejercicio si te parece útil, puedes llevarlo a cabo con un txt, con post-its o con lo que te funcione a ti.
Hablar con el equipo, me gusta mucho pedir consejo o incluso comparar ideas. Creo que con ello se consigue que el proyecto sea más fluido y que no se distinga de primera mano que parte codificó cada persona. No obstante, es muy importante no agobiar al resto, me gusta enviar en estos casos un mensaje y que me contesten asíncronamente o si quieren hacer una videollamada, pero siempre cuando estén libres y no moleste. Porque al final, dejar que el resto se concentren también es necesario.
Y, nada más. Seguro que tú también tienes muchos trucos para tratar de afrontar la curva de entrada a un proyecto nuevo con una tecnología nueva. Y sino, es momento de que tomes los que veas que te van a servir y crees los tuyos propios. Pero lo más importante, recuerda que siempre habrá una curva de entrada y que irás ganando efectividad y confianza con el tiempo. No somos robots que podamos cambiar de configuración y comenzar a trabajar a la perfección el primer día.