Dentro del mundo del desarrollo web hablando específicamente del Backend, existe un concepto llamado API, que no es más que una interfaz para exponer servicios o recursos que deberán ser consumidos por el frontend.
El problema.
Para crear un Api, es importante conocer todos los aspectos de las reglas de negocio a implementar, así como los requerimientos de los clientes (navegadores, apps, refrigeradores, etc.), sin embargo no es siempre posible tenerlos todos desde el inicio del proyecto.
Propuesta.
Para resolver ese problema temporal/a sincrónico y no perder tiempo esperando a los demás integrantes de otras áreas como frontend, producto o diseño, podemos empezar a pensar en las tareas generales que si o si deben estar presentes el producto final y dividirlas según su temporalidad.
La propuesta consiste en definir 3 temporalidades principales, sin embargo cabe aclarar que esto depende mucho del contexto en que se encuentre el proyecto pero puede servir como orientación general.
Inicio del proyecto
A pesar de que en este punto no se conoce mucho sobre los casos, interfaces, comprobaciones, etc, existe al menos un conocimiento general de qué se hará así como detalles generales. Durante ésta etapa la idea es construir las bases del proyecto y entran diferentes variables de gran importancia.
Los siguientes puntos pueden ayudarnos como guía.
- ¿Debería usar un framework? ¿Cuál?
- ¿Debería usar contenedores?
- ¿Qué dependencias/bibliotecas sé que podría usar?
- ¿Qué servicios de terceros deberíamos usar?
- ¿Tendré que revisar temas de Usuarios, Grupos o Permisos?
- Definir la estructura del código.
- Empezar a escribir test re-utilizables.
Con esas tareas, ya tenemos algunas tareas sobre las cuales trabajar, incluso antes de conocer a fondo las reglas de negocio.
Conocimiento de las reglas de negocio.
Una vez que tenemos en nuestro conocimiento cuales son las reglas de negocio podemos empezar a dividirlas para entender qué nos conviene atacar. Lo ideal es poder identificar los comportamientos/reglas generales y particulares, pues en base a eso podremos trabajar sobre 3 cosas.
- Definir los patrones de diseño a usar.
- Complementar y corregir las dependencias del punto anterior.
- Complementar y corregir los servicios de terceros.
Evidentemente al identificar los comportamientos generales podemos trabajar con bastante seguridad sobre ellos mientras damos tiempo a que se definan las partes más finas del producto como las interacciones.
Aquí también nos daremos cuenta de varios servicios que debemos exponer y trabajar sobre ellos.
Conocimiento de los mockups (Hi-Fi)
Al contar con el conocimiento específico sobre el producto digital, ahora si podemos seguir con el desarrollo y llenar los “huecos” que pudieron quedar pendientes en fases anteriores al desarrollo, así como implementar nuevas funcionalidades no previstas.
Aún en esta etapa dónde el desarrollo está incompleto, tenemos pequeñas funcionalidades que bien pueden ya ser integradas por el equipo de FrontEnd gracias a la división hecha en etapas.
En conclusión ésta es la forma que me parece más lógica y conveniente para aprovechar de mejor forma los tiempos de desarrollo y evitar repetir código o hacer dos veces un mismo proceso debido a una confusión o mal entendido en la planificación.
