Hace pocos días desde la agencia digital Mansalva me preguntaron específicamente: ¿En qué consiste y qué hace un Full Stack Developer?
Automáticamente iba a responder con el juego de habilidades que se conocen para el puesto con los nombres «nerd» del asunto.
Hablarle a gente con muy buena formación en marketing digital, pero con poco conocimiento de código hizo que cambiara mi aproximación al asunto y preferí usar un caso práctico.
Veamos el recorrido de un Full Stack Developer en un cliente concreto para el que desarrollé un sistema.
La tarea
Se requería poseer un entrenamiento como el descripto en el título de esta entrada, pero por sobre todo contar la experiencia real.
Vamos con ello.
Mi cliente en 2017 necesitaba un sistema de gestión que permitiera procesar sus incidentes de service, conectando a los técnicos de la empresa con los clientes finales, a través de la administración y de los gerentes de división durante todo el proceso.
Lo primero que se hace es una lista de requerimientos y en este caso se comenzó desde cero, sin utilizar los restos del sistema anterior.
En Uruguay y particularmente hace unos cinco años atrás, MS Excel era la solución que servía como intermediario y formaba parte de la cultura de la empresa, así que mi aproximación fue comenzar por el diseño de:
Bases de Datos
Una base de datos es un conjunto de tablas que a su vez contienen columnas y filas en donde se almacena el contenido y estas se relacionan entre sí mediante un modelo que se conoce como: Base de datos relacional.
Imagine varios libros de MS Excel que por ejemplo contengan planillas con los datos de los clientes, los datos de los productos de la empresa, los detalles de los técnicos, etc.
Entonces, en principio se diseña este modelo y básicamente mis preguntas circularon alrededor de todo lo que debía contener cada tabla, con lo que obtuve el conjunto de columnas.
Una vez que estaba ese número, comencé a preguntar las relaciones que se daban en el flujo de la empresa entre esas tablas, definiendo los procedimientos de la cultura y aquí destaco la importancia de lo que se denomina:
Los roles
¿Quién puede insertar, consultar o eliminar qué?
¿Un técnico puede consultar el domicilio de un cliente?
¿Un cliente puede consultar el estado de su servicio?
¿Un supervisor puede consultar el total de los servicios históricos que hace un técnico en un período?
¿Un gerente de compras puede consultar cuál es el número de un producto específico en inventario?
Sí, por supuesto.
¿Un técnico puede eliminar un cliente?
¿Un técnico puede consultar lo que le fue asignado a otro técnico?
¿Un cliente puede conocer cuánto queda en el inventario de un producto?
No, por supuesto.
Con el diseño y los roles establecidos, la base de datos puede ser montada y en su momento tendré que utilizar sentencias SQL (Structured Query Language), para insertar, consultar o eliminar una fila en una tabla bajo cierta columna del «Oráculo».
Ahora hay que cuantificar el tráfico que esta base tendrá para devolver la solución del equipamiento necesario para la demanda.
El servidor
Hace unos quince años atrás, el equipamiento de los equipos de la empresa permitía aproximarse a lo que se llama: «Soluciones de escritorio» y por ejemplo con la mezcla de una base de datos de escritorio como MS Access con su motor JIT y la herramienta de programación Visual Basic NET para el diseño de interfases, se podía responder al asunto. Estas dos herramientas han evolucionado notablemente en el último tiempo y permiten muchas funcionalidades, pero por entonces, no eran la solución adecuada.
Este era el escenario de comienzos de siglo y hasta el día de hoy todavía hay soluciones que continúan en esta ruta con los consiguientes problemas de conectividad.
Pero, en el 2017 era impensable recorrer este camino; así que había que montar todo en la archiconocida nube, por lo que es tarea -creo yo- de un buen Full Stack Developer, conocer las mejores distribuciones de hardware para implementar su software.
En este caso, con un servidor Apache, bajo una licencia cPanel con el sistema operativo Linux, alojé la solución.
Luego de analizar el tráfico para evitar atascos y calculando el llamado «uptime», le di arranque al server en donde monté mi base de datos utilizando MySQL.
PostgreSQL era una alternativa, pero aquí el desarrollador tiene que priorizar que esta aplicación va a tener un ciclo de vida largo y para ello; me pareció más razonable ir por la primera opción.
A toro pasado tal vez hoy, preferiría Firebase; pero estábamos en 2017 -recuerde- y necesitamos eficiencia y ser escalables.
Vamos a arrendar un DNS para el proyecto de tal manera que sirva como la puerta de transacciones y preparamos las capas de seguridad para mantener las visitas «indeseables» fuera.
Por cierto; todo sistema es atacado -en mi experiencia- tarde o temprano; ya sea bajo el modelo DDoS o algún otro y el Full Stack debe conocer este tipo de amenazas cuando diseña los contenedores.
En este caso preferí montar un cdn como Cloudflare para asistirme en la tarea de profilaxis, aunque tiene algunos costos de rendimiento.
Back End
Bueno, ya tengo mi base de datos que va a servir como punto de conexión y el contenedor para soportar el tráfico.
Ahora voy con lo que hace un Back End Developer; es decir, voy a conectar la base de datos con un conjunto de procesos que harán las tareas de:
- Insertar los registros
- Leer los registros
- Actualizar los registros
- Eliminar los registros
Para ello necesito un lenguaje de back end y en este caso de estudio la elección recayó sobre el siempre fiable: PHP
Entonces acondicionamos nuestro servidor con los parámetros en los archivos de configuración para que use PHP y allí vamos.
Todo el conjunto de buenas prácticas posible se aplica aquí.
¿Qué es un conjunto de buenas prácticas?
Bien, puedo finalizar mañana mi relación contractual con el cliente y éste puede optar por otro desarrollador para seguir la tarea.
Es deseable que quién venga detrás, pueda leer y actualizar mi código sin estar días (¿meses?) tratando de descubrir qué fue lo que quise escribir.
Comentar el código es fundamental, siempre. Es decir documentar en uno o varios lugares qué hace cada cosa.
Tedioso pero necesario.
Luego llegó la tarea de seleccionar desde los métodos de conexión con la base de datos, hasta el patrón del ciclo del software que se conoce en la jerga como: modelo-vista-controlador o «Patrón MVC«.
Es posible aquí utilizar ciertos frameworks para PHP que ya vienen con una serie de librerías y utilizan los modelos de buenas prácticas descriptos antes y en este caso preferí Symfony que ahorra mucho tiempo luego en la distribución del sistema. También se puede utilizar Laravel o el más liviano y siempre querido CodeIgniter.
Bien, esa es la tarea de un Back End Developer y tiene que conocer mínimamente estas herramientas si va con PHP.
Ya lo sé, soy un desarrollador veterano y por tanto me siento cómodo con mi destornillador preferido, pero si la opción fuese un lenguaje más moderno de back como python, le sugiero darle una mirada al framework Django
Es interesante comentar que durante la construcción de esta capa, tuve la posibilidad de hacer un pequeño procedimiento que luego publiqué en GitHub para ayudar a otros desarrolladores y entre este repositorio, stackoverflow y el manual de PHP, este developer, pasa gran parte de su día, preguntando, respondiendo y si puede, colaborando.
Bueno; ya mi aplicación se conecta con la base de datos y comienza a devolver información mediante los formularios que al principio de forma rústica (archivos de texto plano), son capaces de responder las primeras preguntas, por ejemplo:
¿Cuáles son los números de incidentes de service que tiene asignado el técnico X?
Bien; pero los funcionarios de la empresa no están muy cómodos con los textos planos y un botón gris en el ángulo superior izquierdo de la pantalla; así que tengo que llamar a otro developer que se denomina:
Front End
Ahora que me visto de Front End Developer, tengo que basar mi trabajo en la experiencia del funcionario de la empresa y del cliente final.
Para ello, primero necesitaré darle un diseño y un juego de estilo a mi aplicación.
Bien; voy a utilizar aquí un lenguaje de maquetación que se denomina HTML (Hypertext Markup Language) y las hojas de estilo en cascada conocidas como CSS (Cascading Style Sheets).
Cada vista de mi aplicación seguirá estas reglas para mejorar la experiencia de uso del sistema (conocida en el negocio bajo el nombre de: usabilidad).
Hoy en día este término ha sido ampliado a UX (user experience) y UI (user interface); pero recuerde que yo provengo del pleistoceno y estos son temas de diseño web.
Para resolver la tarea me incliné por dos opciones que son mínimamente necesarias para un Front End, es decir un «framework» o marco de trabajo que incluya un juego completo de estilo como Bootstrap y algo más liviano para los técnicos en sus dispositivos móviles por lo que aquí utilicé Skeleton CSS que por su peso es un boilerplate más que un framework.
Ahora mi aplicación ya se conecta y hace todas las operaciones entre sus distintas páginas con una grilla fluida lo que permite que se pueda utilizar en diversos dispositivos.
Llega el momento en donde ambos roles serán parcialmente unificados mediante un lenguaje y sus librerías; así que toca el turno de:
Javascript
Javascript es el lenguaje principal que se utiliza desde el lado del navegador y por su uso, la web se volvió dinámica.
A partir del año 2005 con la creación de un objeto denominado AJAX (Javascript asíncrono + XML) se comenzó a implementar un conjunto de código ya no del lado del servidor, sino que se ejecuta directamente en el navegador.
Esta técnica fue evolucionando rápidamente y hoy es impensable desarrollar sin utilizar alguno de los sabores disponibles de esta herramienta.
En mi caso, primero para los funcionarios y luego para los técnicos, vino en auxilio una librería que estuvo muy de moda que se denomina jQuery.
Con jQuery cumplí al principio tanto las funciones de Back como de Front, mejorando la experiencia primero para los integrantes de la empresa y luego para los clientes.
Explicar lo que hace jQuery es tan sencillo como recordarle al lector lo que sucede cuando ingresa un conjunto de caracteres en una caja de un buscador.
Antes que lo complete totalmente, la caja «sugiere» un término leyendo en tiempo real los primeros caracteres que se le ingresan, es decir; autocompleta.
Luego también puedo en el sistema ordenar una tabla haciendo click en el cabezal de cada columna, por ejemplo usando el por nombre del cliente o un número de service, en cualquier aplicación del sistema.
Es más, mientras Ud. lee estas líneas, en ciertas partes del back end, el PHP está siendo sustituido por una librería de Javascript denominada Node.js allí donde sea posible. Mientras que algunos componentes del Front End ya están montados utilizando el framework Vue.js.
En resumen ¿qué es Full Stack Developer?
El sistema de mi cliente ha procesado en esta etapa en la que ya está maduro luego de poco más de cinco años, unos 36000 incidentes.
Los técnicos tienen en sus dispositivos los services con todos los datos necesarios al llegar al domicilio del cliente.
Este cliente firma digitalmente en el dispositivo del técnico el formulario de la visita del service.
Recibe notificaciones de su estado del servicio y tiene una web específica para chequear su historial.
Los funcionarios administrativos y de gestión, asignan, trazan, informan y le comunican a los diversos sectores de la empresa acerca del estado de un incidente cualquiera y su recorrido comercial.
Los supervisores en su consola, tiene acceso a todas las capas para monitorear el servicio e inclusive pueden realizar las acciones de marketing que van desde lanzar una encuesta de satisfacción del servicio, hasta un boletín de email marketing para mantener el llamado «engagement».
El sistema se protege a su vez con el envío de los respaldos a un segundo servidor remoto para cubrirse del eventual fallo por cualquier circunstancia.
Cuando me preguntaron: ¿qué hace un Full Stack Developer?, preferí entonces contestarlo de este modo.
En este ejemplo de la realidad usamos:
- PHP 7.x
- SQL con MySQL
- HTML+CSS con Bootstrap y Skeleton CSS
- Vanilla JS (Javascript puro)
- jQuery
- Chart.js (sí; los supervisores quieren gráficas)
- React.js
- Vue.js
Ah, por último; estoy en pleno desarrollo de la API del sistema para enlazar empresas que quieran tercerizar sus incidentes de service, lo que me llevará a implementar los webservices necesarios; pero esa; esa es otra tarea.
Si le interesa esta lectura, puede dejar sus comentarios en esta entrada o escribirme un email utilizando el plugin para WordPress que hice en PHP en la pestaña Contacto.
