Hoy en día, en la mayoría de las empresas prácticamente no hay perfiles especializados únicamente en desarrollo frontend. Hay personas que no se deciden en qué parte les gusta más, las hay que les gusta tanto backend como frontend, y las hay que no les queda más remedio que ser “fullstack”. Por este motivo, al estar cubriendo varias responsabilidades y entre la trepidante velocidad y alta productividad que se le demanda en el día a día a un desarrollador, puede ser difícil que el programador/a se haya parado a pensar en qué consiste exactamente su trabajo y lo haya podido desgranar. Esto es precisamente lo que vamos a intentar hoy, al menos, desde el punto de vista de un desarrollador frontend de Neoco.

El Analizador

Toda funcionalidad nace de un requisito y a ese requisito hay que revisarlo, ya que se pueden dar varias situaciones:

• Que el “Product Owner” lo haya definido perfectamente y se pueda estimar directamente. (¿Alguien ha tenido el placer de vivirlo?).
• Que sea un requisito con una complejidad enorme y deba ser seccionado en funcionalidades más pequeñas.
• En el caso de ser un flujo, que haya algún caso no contemplado.
• Que para dar una estimación, se requiera de una investigación previa.
• Que se dependa de un recurso gráfico por parte del diseñador para completarlo.
• Que el backend aún no soporte la funcionalidad, por lo que se deberá aplazar su desarrollo o falsear la llamada al backend desde el frontend.
• ¡Y muchas más!

Como véis no son pocas las situaciones en que un requisito puede no estar preparado para su desarrollo, por lo tanto, el rol del "Analizador" necesita resolver todos los bloqueos y al final proveer de una estimación. Para este tipo de tarea, es cierto que no hace falta ser desarrollador frontend, sin embargo, para hacerlo con un mínimo de calidad aceptable, sí que hay que tener unas nociones básicas de desarrollo frontend.

El Maquetador

Una vez tenemos el requisito listo, ya podemos hacer el trabajo más básico y por el cual tiene más sentido empezar: añadir el HTML y el CSS. La mejor manera para maquetar es hacerlo en un entorno aislado, por eso nosotros usamos la herramienta Storybook. Hacemos un pequeño análisis sobre el diseño para detectar las diferentes versiones que pueda tener un componente y nos ponemos manos a la obra. Aunque sea el trabajo más básico, no por ello es menos importante ya que son las piezas de código sobre las que asentaremos el proyecto, por eso es importante tener en cuenta las siguientes directrices:

• Los componentes que desarrolla el maquetador raramente albergarán estado. Es mucho mejor que únicamente reaccionen al cambio de sus propiedades.
• Si necesitan reaccionar a alguna acción, como responder al click de un botón, el manejo de la “callback” será delegada al componente padre.
• Es crucial tener en cuenta la composición a la hora de construir este tipo de componentes ya que sino podemos terminar con un puñado de condicionales para soportar los diferentes casos de usos que nos haya propuesto el diseñador.

El Integrador Funcional

Un paso más allá del “Maquetador” nos encontramos al “Integrador Funcional”, que se encarga de organizar los distintos componentes desarrollados por el Maquetador en componentes más complejos, como pueda ser un formulario o una pantalla entera. Digamos que en esta situación nos ponemos el casco y empezamos a juntar las piezas de Lego. Estos componentes serán los que albergarán estado, por tanto, nos podemos encontrar teniendo que implementar lógica para añadir y eliminar elementos de una matriz o por ejemplo implementar un control y subida de imágenes y unir los cables que el “Maquetador” nos ha dejado preparados.

El Integrador Backend

En este último rol, ya solo nos queda conectar nuestros componentes con la lógica de negocio del servidor. Para ello, crearemos las funciones necesarias para realizar peticiones a las APIs REST, GraphQL, etc. Luego, en caso de ser necesario aplicaremos alguna transformación a los datos que vayamos a enviar o recibir del servidor. Finalmente, modificaremos los componentes creados por el “Integrador Funcional” para que utilicen estas funciones y trabajen con los datos y estructuras finales. Este rol es responsable de hacer las modificaciones pertinentes a cualquiera de los componentes ya existentes que tengan un desajuste respecto a lo que se diseñó y desarrolló sobre el papel.

Conclusión

Por ahora estos son los cuatro roles o distinciones en cuanto a los diferentes trabajos que hace un desarrollador frontend que hemos decidido considerar en Neoco. Hemos tenido en cuenta una distinción que contemple unos roles que se puedan solapar lo menos posible, para así poder dividir los trabajos entre diferentes personas en caso de ser necesario. Seguro que se pueden añadir más detalles sobre cada uno de los roles e incluso añadir más roles, sin embargo, en este artículo la intención ha sido enumerarlos sin entrar muy en detalle y dar a conocer cómo pensamos sobre el desarrollo frontend en Neoco.

¡Salud!