Ha pasado el suficiente tiempo como para poder haberme generado una opinión fuerte sobre cuáles deben ser los requisitos mínimos PARA MÍ de todo proyecto que se preste en 2024.

Docker y Make

Una de las primeras cosas que me gustaría ver en un proyecto es que tenga un Makefile y un Dockerfile.

Con el primero seremos capaces de simplificar tareas cotidianas como ejecutar los tests, hacer una build del proyecto, comprobar el formato o simplemente ejecutarlo en local.

Para que la ejecución de todas estas tareas sean trivial me apoyaría en Docker, y tal vez Docker Compose, lo que nos va a permitir encapsular nuestra aplicación, permitiendo controlar el entorno donde se ejecuta, pasando a ser el mismo tanto en nuestro local como en producción.

Testing

Una vez que el contexto de la aplicación está controlador con Docker, el siguiente punto clave en todo proyecto del que forme parte es el testing.

Si queremos estar seguros de lo que ponemos en producción, es imprescindible hacer pruebas, idealmente automáticas, porque si no serán manuales y a cargo de nuestros usuarios.

Es por ello que deben existir diferentes tipos de tests en nuestro proyecto:

• Unitarios:
  • En el rango de centenares o miles.
  • Cumplen con los principios F.I.R.S.T.
• Integración
  • En el rango de decenas o centenares.
  • Validan la integración de la aplicación con el exterior.
  • Son más lentos que los unitarios.
• Aceptación
  • En el rango de decenas o centenares.
  • Validan que la aplicación desde un punto de vista muy exterior.
  • Son los más lentos de todos.

CI/CD

Todo proyecto que pretenda tener un periodo de vida largo manteniendo una calidad alta necesita automatizar ciertas tareas clave, para ello es fundamental tener una pipeline potente.

Y con potente quiero decir:

• Tiene una fase inicial donde se valida que el código tiene un formato correcto, los tests están en verde y si es el caso los tipos son correctos.
• Una vez que nuestro código es “válido” es ahora de generar la nueva versión de nuestra aplicación.
• Una vez que la nueva versión está generada, es hora de desplegarla, en que entorno es algo que prefiero no entrar, ya que cada aplicación es un mundo.
• Cuando nuestra aplicación está desplegada es momento de probar que todo sigue funcionando correctamente, para ello es necesario que lo validen de forma automática unos tests que se comportaran como si fueran un usuario real.
• Si estos tests fallan es necesario hacer un rollback automático, en el rango de segundos y sin intervención humana.

Os dejo por aquí un esquema de un pipeline tipo

Arquitectura

Por último, y ya más a nivel de código puro y duro, creo que necesario estructurar nuestro proyecto de tal forma que sea fácil:

• Navegar.
• Cambiar.
• Testear.

Para lograrlo lo que a mí más me funciona es utilizar alguna estructura en capas, podemos pensar en Ports & Adapters, Clean Architecture o Arquitecture Hexagonal. De esta forma podemos separar las diferentes responsabilidades de nuestra aplicación, en diferentes capas, lo que hará que todo sea más sencillo.

Estoy pensando en cosas como buscar como se hace la integración con un tercero en la capa de Infraestructura, como se hace la lógica de negocio en la capa de Dominio o como se presenta la información en la capa de Delivery.

¡Espero que os haya gustado y os sirva como inspiración!