Documentando y programando al mismo tiempo usando Excel
Después de trabajar en varios proyectos con base en CRUD (Create, Read, Update & Delete) pude darme cuenta que perdía mucho tiempo escribiendo código estándar y que no agregaba valor en sí mismo al aplicativo, por dar algunos ejemplos: Formularios en HTML, objetos base de la API REST, conexión entre el HTML Template y la lógica del controlador (Angular), creación de las tablas en la DB y sus vistas (En caso de que aplicaran), etc. Se podría decir que el Pareto aplicaba totalmente: 80% del tiempo era invertido en actividades que no agregan valor y un 20% en las que si lo agregan (Algoritmos, lógica no estándar, etc.).
Debido a lo anterior, me puse a revisar detenidamente los proyectos para identificar que era lo que se repetía en varios, encontrar un “Común denominador”. Una vez que lo encontré la pregunta seguida fue ¿Qué puedo hacer yo para no volver a perder tiempo en esto? Los que hayan trabajado con una API REST sabrán que existen múltiples partes o rutas dentro de la petición: ¿Tiene el usuario con X rol permiso para trabajar con Y objeto?, ¿Tiene el usuario con X rol permiso para trabajar con Y atributo del objeto?, ¿Debo ejecutar alguna función posterior a que se realiza determinada acción?, ¿Qué campos son obligatorios para crear X objeto y que campos son opcionales?, ¿Qué campos se pueden actualizar y cuales no por parte del usuario?, ¿Qué campos los agrega el Backend al crear?, ¿Qué campos modifica el Backend?, ¿Debo mandar la acción a un log o no?, etc.
Lo primero que se me ocurrió fue la creación de un software que me ayudara a hacer esto, un conjunto de formularios que me ayudaran a crear archivos que pudiera integrar a mi proyecto no obstante no era práctico porque debería invertir mucho tiempo en esto y ya tenía en puerta un proyecto donde participarían >10 ingenieros y necesitaba que se siguieran ciertos lineamientos. Fue entonces donde dije: Si uso las funciones de “SI()” y de “CONCATENAR()” de MS Excel puedo comenzar a generar código. Lo mejor será que esos archivos servirán de documentación para quien quiera trabajar con X objeto y saber que campos lo forman, como mandar las peticiones, como solicitar información, etc (Cuando tienes +60 EP se vuelve complicado no tener documentación, créeme).
Comencé creando una tab de datos generales del objeto en cuestión:
Normalmente cuando ya tenemos realizado el análisis de lo que necesita el cliente yo procedo a crear la base de datos, y es esto mi punto de partida. La segunda tab consistió en una tabla donde al llenar los datos me generara el código de la base de datos (Yo trabajo con MariaDB); obviamente esto implicó el uso de fórmulas de Excel (SI & CONCATENAR) y de listas (Combo boxes):
El resultado de llenar la tabla es el siguiente SCRIPT:
Luego me pasé a crear las tabs para el CRUD tanto del Backend como del Frontend. Estas tabs consisten en los campos de la base de datos con columnas donde cualquiera puede agregar “checkmarks” según lo que apliqué a cada campo:
IMPORTANTE: TODAS LAS CELDAS DEBEN ESTAR LIGADAS PARA EVITAR REPETIR INFORMACIÓN.
Para dar unos ejemplos, “Must have for create” son campos que deben estar forzosamente para poder crear un registro, “Allow for update” son campos que pueden ser actualizados usando la API y “Backend add value” son campos que nuestra lógica del lado del servidor agregará con base a nuestras reglas particulares.
Agregué una segunda tab para la acción READ:
En esta tabla consideré lo que normalmente podemos usar en una API al mandar una petición GET: “Valid get parameters” es para permitir que el usuario filtre utilizando el nombre del atributo y el valor deseado de la siguiente forma “https://core.my_cool_project.com/api/objetoX?name=Juan” y “Allow fields” es para especificar que campos requieres para la consulta (No siempre necesitamos traer el 100% de campos).
Lo siguiente en una lógica sería el poner restricciones sobre los valores que pueden aplicar a cada atributo, es por esto que también cree una tab con una tabla de validación:
Se que existen más validaciones, pero en mi caso estas son las que uso normalmente, si saliera una diferente no me cuesta nada agregarla de forma manual. Creo que con los nombres de las columnas será suficiente para que entiendas la finalidad de cada una.
Hasta este punto tenemos las tabs que hasta alguien que no sabe de código puede utilizar; ahora pasaremos a lo que estoy seguro que te importa más, el código que se genera de forma automática.
Antes de continuar debo comentarte que mi generador de código está enfocado en los siguientes frameworks: Frontend Angular 10+ y Backend CodeIgniter 3. Tu puedes crear tu archivo para que trabaje con el lenguaje y framework que tu desees. Dicho esto sigamos.
La primer parte del generador de código está enfocado en Angular.
Yo permito seleccionar entre 3 opciones: 1) Create — Solo campos obligatorios. 2) Create — Campos obligatorios y no obligatorios. 3) Update — Campos permitidos.
El resultado de configurar todo de forma correcta es un ahorro aproximado de 70 líneas de código CRUD:
En el código de arriba tengo funciones como: loadUserForm que me crea la ReactiveForm, el arreglo errorMessages que contiene que error desplegaré en caso de no cumplir con las validaciones, initUser que me trae la información del usuario, createUser que me permite interactuar con la API, etc.
Oye, ¿y el HTML? Este también lo genero pero en otra tab donde puedo agregar las clases de CSS y textos al botón que necesite:
De esta forma evito perder tiempo entre el formulario y el controlador de angular.
Ahora sigue la parte del Backend, lo primero es agregar un poco de configuración con base a la ruta lógica de la que hablaba al inicio:
Como resultado obtengo el siguiente código:
Dicho código yo lo copio y lo pego en mi modelo de CodeIgniter y utilizando mi código estándar me permite tener la API funcionando.
Con esto se puede decir que mato 5 problemas de un tiro:
a) Tengo un archivo de MS Excel con la información completa que me sirve como documentación.
b) Genero código tanto para el Frontend como para el Backend y me ahorro tiempo y líneas de código.
c) Me aseguro de tener código estándar sin importar quién es el que trabaje en la creación del modelo.
d) Evito errores al integrar el Frontend y Backend por usar mal el nombre de algún atributo.
e) Puedo establecer una metodología de trabajo para mi equipo.
El objeto sobre el que trabajo tiene menos de 10 atributos pero cuando tiene un objeto con más de 40 atributos es cuando felicitas tu “yo” del pasado por haber trabajado en este tipo de archivos.
Mi archivo de Excel al día de hoy cuenta con 22 tabs y va mejorando día a día para facilitar mi trabajo y el del equipo, en este artículo muestro de manera general su funcionamiento con la finalidad de que veas como soluciones simples pueden ahorrarte tiempo, en este caso todo esto se logró utilizando dos simples funciones de Excel (Google Sheets también las maneja): SI() y CONCATENAR().
NOTA: Al ser mi archivo de alto valor agregado para mi actividad profesional no lo comparto sin embargo si tienes dudas sobre cómo crear el tuyo o te atoras en algo con gusto puedo ayudarte, solo deja comentarios.
