Soy Efraín Hidalgo

Introducción 🎬

API Rest tienda de productos desarrollada con Laravel 12, PHP 8 y Docker.

En este proyecto he trabajado de forma meticulosa con los siguientes aspectos:

• Docker para levantar el proyecto.
• Aplicando de forma relativamente estricta metodologías y arquitecturas limpias como DDD y arquitectura hexagonal.
• Microservicios, contenedores separados para el backend, BD para tablas de Laravel, BD de mi dominio desacoplado del framework.
• Realización de tests de Aceptación, Integración y Unitarios que cubren la totalidad de mi código.
• Especial atención en los principios SOLID y clean code.
• Flujo de trabajo Git Flow (aunque sea el úníco desarrollador).

Aunque este proyecto lo haya desarrollado con DDD y arquitectura hexagonal por las expectativas de que creciera y fuera más mantenible, no es algo que sea apropiado para todos los proyectos, ya que si vamos a desarrollar un proyecto más pequeño lo más pragmático sería hacer un simple MVC o seguir la dinámica de desarrollo por defecto de Laravel.

En resumen, el proyecto gestiona los productos (con sus variantes) que pertenecen a una categoría donde se pueden añadir al carrito para confirmar la compra.

Mi proceso y sensaciones 💭

Antes y durante el desarrollo de este proyecto he realizado algunos cursos para afianzar, mejorar y pulir mis conocimientos sobre las últimas novedades de Laravel, DDD, Arquitectura hexagonal y testing, aunque ya tuviera ciertos conocimientos siempre hay algo nuevo que aprender, ya que quería desarrollar el proyecto lo más pulido posible (en base a mis capacidades y conocimentos) ya que en este caso era yo el que tomaba las decisiones.

La verdad es que cuando inicié el proyecto aún no me había involucrado demasiado con la IA, por lo que no la utilicé desde el principio, una vez había desarrollado toda la estructura src de DDD, todos los endpoints de la API y algunos tests empecé a integrar la IA en el proyecto de forma progresiva.

Empecé preguntándole mejoras y optimizaciones a chatgpt, después pasé a github copilot y finalmente me pasé a Windsurf que es donde me encuentro ahora, durante el proceso me di cuenta de varios detalles de por ejemplo DDD que estaba aplicando mal.

Uno de los detalles de DDD que estaba aplicando mal era que estaba gestionando las instancias del modelo OrderLine desde el propio caso de uso, en lugar de hacerlo desde el Aggregate Root Order, que es como debe de ser. Una vez identificado lo refactoricé.

Cuando se utiliza la IA de apollo en el desarrollo, hay que entender y analizar siempre sus propuestas de código, si nos parecen correctas y mejoran el código actual las podemos aplicar, y si no se entiende se le vuelve a preguntar a la IA hasta entenderlas.

Desde mi punto de vista se interioriza mucho mejor cualquier concepto de programación trabajando de forma empírica en un proyecto y apoyandose en la IA (teniendo en cuenta el párafo anterior), que realizando cursos al respecto, o todavía mejor, utilizando ambas formas.

Soy consciente de que al proyecto aún le falta un poco para considerarse MVP (proyecto mínimo viable), concretamente el proceso de confirmación de compra y el posterior flujo de estados del pedido, pero independientemente de eso he tratado de pulir y optimizar al máximo el código y lógica actual del proyecto.

Otros detalles a los que le he prestado especial atención es a todo el naming de clases y propiedades (aplicando PSR-12), enfocándome en asignar nombres lo suficientemente descriptivos sin pasar la línea roja de la redundancia, y por supuesto absolutamente todo en inglés.

Aunque no tenga la habilidad de hablar inglés de forma fluida, sí que tengo una comprensión de lectura/escritura lo suficientemente buena para escribir y leer código en inglés (obligatorio), y si hay algo que no termino de comprender lo consulto con la IA o el traductor.

Código 💾

Después de toda la chapa previa pasemos a comentar un poco el código, para levantar el proyecto y ejecutar los tests he dejado los ficheros README.md y la versión en español README-ES.md con las instrucciones de instalación. También incluyen instrucciones para usar PHP CS Fixer y Laravel ide helper durante el desarrollo.

Fichero CONTRIBUTING.md donde defino las reglas para los desarrolladores de como crear ramas y commits y de como hacer los merge mediante pull requests.

Aunque el proyecto únicamente contiene el backend/API de la tienda (shop), también está preparado para contener el backend del backoffice (panel de administración), podras observarlo en varias partes del proyecto.

Con respecto a los tests, he utilizado únicamente PHPUnit (aunque conozco un poco Pest), y mi forma de segmentar los tests es la siguiente:

• Una "testsuite" para Backoffice (aunque actualmente no exista), otra para Shop (backend de la tienda) y otra para Shared (módulo compartido de DDD). Definidos en phpunit.xml.
• Un "group" para tests de "feature" (tests de aceptación/aceptance), otro para "unit" y otro para "integration". Definidos con el atributo group en cada método de test.

He implementado un sistema de throttle con un Middleware de Laravel en bootstrap/app.php para limitar a un máximo de 5 intentos de login en un minuto para bloquear ataques de fuerza bruta.

También he implementado un manejador de excepciones (ExceptionHandler) en bootstrap/app.php para manejar las excepciones de forma global y no tener que estar capturándolas de una en una, donde se pasa la excepción al ApiResponse.php para formatearla de forma estándar hacia el exterior (frontend).

Y bueno, en resumidas cuentas, todo el código de dominio está en /src, los Controllers en /app/Http/Controllers/Shop, y luego están por ahí los Providers, Migrations, Factories, Seeders, etc.

¿Consideras que hay algo en el proyecto que pueda mejorar u optimizar? ¡Házmelo saber para valorarlo y aplicarlo si lo considero oportuno!.

Repositorio github

Mi forma de verlo 👀

Estamos viviendo una época en la que la profesión del desarrollador está viviendo un cambio nunca antes visto con la aparición de la inteligencia artificial, donde incluso hay una parte del sector que piensa que la IA va a reemplazar a los desarrolladores.

Mi opinión al respecto es que la profesión va a evolucionar progresivamente a otra forma de trabajar, donde antes éramos más "picadores de código", y ahora vamos cada vez más hacia "solucionadores de problemas", donde en cualquier caso siempre hay que tener de base los fundamentos de la programación, y es por eso por lo que pienso que siempre se va a necesitar un desarrollador para manejar y refinar lo que la IA nos ofrece.

Lo que nos conlleva a ir subiendo escalones en cuanto a la complejidad de los desarrollos, donde las tareas y decisiones más sencillas las realiza la IA y al desarrollador le queda mas tiempo para analizar y solucionar problemas más complejos.

Analogía futbolística ⚽️

Me gusta verlo con la siguiente analogía en comparación con un partido de futbol:

Antes de la aparición de la IA un desarrollador ejercía tanto de entrenador como de los jugadores, y después de su aparición, los jugadores son potencialmente ejercidos por la IA.

Donde el desarrollador va delegando responsabilidades de los jugadores a la IA y analizando su desempeño, y en el caso de que la IA no consiga marcar gol, sea el desarrollador/entrenador el que decida mandar a la IA al banquillo y salir él a marcar el gol.

Lo que nos conlleva a ir subiendo escalones en cuanto a táctica y estrategia de juego, donde las jugadas de campo más sencillas las realiza la IA y al desarrollador/entrenador le queda más tiempo para analizar tácticas y estrategias más complejas.

Sobre mí 🙋🏻‍♂️

Algunas de mis naturalezas como persona son la objetividad, el pragmatismo y el perfeccionismo, y sí, entiendo que éstas dos últimas pueden parecer contrarias, y realmente lo son, pero hay un matíz que determina si aplico de forma instintiva una u otra.

Y ese matíz es cuanto me apasiona o entusiasma cierta tarea/acción/labor, cuando algo me gusta demasiado sale mi lado perfeccionista de forma automática, tratando de aprenderlo/refinarlo/optimizarlo todo lo posible, y como podrás imaginar, el desarrollo de software está incluido, de igual forma soy consciente de que no acarrea solo cosas buenas, y que también es negativo cuando esa perfección hace perder demasiado tiempo sin ser necesario a veces. Es por eso que en esas situaciones trato de forma consciente de ser más flexible para poder seguir progresando de forma fluida.

Y la otra parte, el pragmatismo, nace en todo lo demás, en pequeñas tareas cotidianas del día a día que simplemente necesiten ser completadas, en esos casos no me complico demasiado.

Mi opinion respecto al purismo en desarrollo de software 🤔

Ahora bien, con respecto al purismo sobre cualquier aspecto en desarrollo de software, es algo que en teoría está muy bien mientras todo fluye, trato de aplicarlo en la medida de lo posible, pero en el momento que nos cuesta encontrar la solución purista para determinado problema hay que pasar a ser más pragmático y objetivo. Esa es mi forma de entender que en el desarrollo de software hay que tratar de seguir las mejores prácticas pero en determinados casos hay que ser flexible.

Hardware para programar ⌨️

Todo mi entusiasmo al desarrollo no solo lo aplico a nivel de sofware, también trato de optimizarlo a nivel del hardware de los periféricos de entrada, y aunque lo siguiente se desvía un poco del motivo por el que estás leyendo mi CV, realmente me gustaría comentarlo.

Con el paso del tiempo como desarrollador he ido cuestionando los ratones y teclados tradicionales, llegando a la conclusión de que debían exisir periféricos más ergonómicos y prácticos. Lo primero que probé fueron los ratones ergonómicos zurdos, y aunque no son tan extraños en realidad, sí que me costó encontrar uno para la mano izquierda que fuera lo suficientemente grande, ya que otros que probé me arrastraban los dedos por la mesa.

Donde finalmente terminé con el siguiente ratón que simplemente cumple con las características que buscaba: zurdo, vertical y grande.

Y con respecto al teclado he tardado más tiempo en tomar una decisión ya que la diversidad de teclados diferentes que podemos encontrar es amplia. Llegué a la conclusión de que la distribución de las teclas de los teclados típicos estaban obsoletas, ¿por qué cada fila de teclas está ligeramente desplazada con respecto a otras filas? 🤯, resumiendo, esto es así desde que se inventaron las máquinas de escribir en las que existía ese desplazamiento para no atascar las palancas, y desde entonces, dada la aceptación de la sociedad se ha mantenido así.

Donde finalmente me decidí por el siguiente teclado dividido ortolineal (filas de teclas sin desplazamiento), en este caso lo que está desplazado es las columnas para ajustarse a la longitud de cada dedo, donde en las teclas negras tengo macros, y las teclas grises encajan en el abanico del movimiento del dedo pulgar ¡ahora sí que le veo el sentido! 😁.

Además de, ya que estábamos, sustituir también la distribución querty por colemak dh (voy all-in), que concentra la mayoría de pulsaciones (dado el idioma inglés) en la fila central, por lo que es más eficiente en la escritura.