TL;DR
Este repositorio contiene mis soluciones a los retos semanales de programación de la comunidad MoureDev durante 2022. Completé 18 de los más de 50 retos publicados, cada uno resuelto en Java con tests automatizados y pipeline de CI con GitHub Actions.
No es un “proyecto” en el sentido clásico. Es un campo de entrenamiento donde practiqué lógica, estructuras de datos, algoritmos y disciplina de desarrollo en Java.
Por qué lo hice
En 2022 estaba aprendiendo Java en serio y necesitaba un lugar donde practicar de forma constante y medible. Los retos de MoureDev me daban exactamente eso: un problema nuevo cada semana, con dificultad variable, que me obligaba a pensar en lógica pura.
La decisión clave no fue “resolver retos”. Fue cómo resolverlos:
- Cada solución con su test unitario correspondiente.
- CI con GitHub Actions para validar que todo compila y pasa tests en cada push.
- Código organizado por reto, no un archivo gigante con todo mezclado.
Quería que el repositorio fuera evidencia de hábito, no solo de resultado.
Qué tipo de retos hay
Los retos cubren un espectro amplio de problemas:
- Manipulación de strings: palíndromos, anagramas, cifrados, parsing.
- Matemáticas y lógica: números primos, fibonacci, bases numéricas, operaciones con fechas.
- Estructuras de datos: listas, mapas, pilas, árboles.
- Algoritmos clásicos: búsqueda, ordenación, recursividad.
- Problemas de modelado: máquinas de estado, validadores, simulaciones.
Cada reto tiene su clase Java con la solución y su clase de test correspondiente.
Decisiones técnicas
Tests como requisito, no como extra
Desde el principio decidí que ningún reto se consideraba “terminado” sin su test. Eso me obligó a pensar en casos borde desde el planteamiento, no solo en el happy path.
Parece un detalle menor, pero cambió mi forma de abordar cada problema: primero pensaba qué entradas podía recibir, luego escribía los tests y por último la solución.
CI con GitHub Actions
El pipeline es simple: en cada push, se compila con Maven y se ejecutan todos los tests. Si algo rompe, lo sé inmediatamente.
Para un repositorio de práctica puede parecer excesivo, pero me enseñó dos cosas:
- Que integrar CI desde el principio cuesta poco y evita sorpresas.
- Que tener un badge verde en el README es un incentivo real para no dejar tests rotos.
Badge personalizado con GitHub Action propia
Además del badge de CI estándar, creé una GitHub Action propia que cuenta automáticamente cuántos retos llevo resueltos y genera un badge dinámico con ese número. Fue un ejercicio interesante de automatización: parsear el repositorio, contar soluciones y actualizar el badge en cada push sin intervención manual.
Organización por reto
Cada reto tiene su propia clase dentro de un paquete organizado. Eso evita colisiones de nombres, facilita la navegación y permite correr tests de un reto específico sin ejecutar todo.
Dónde aprendí más
Pensar en bordes antes que en lógica
Los retos más formativos no fueron los más difíciles. Fueron los que tenían entradas tramposas: strings vacíos, números negativos, listas con un solo elemento, desbordamientos de enteros.
Aprender a anticipar esos casos antes de escribir código es una habilidad que uso todos los días.
Recursividad vs iteración
Varios retos admitían ambas soluciones. Implementar las dos y comparar legibilidad, rendimiento y riesgo de stack overflow me dio intuición práctica sobre cuándo usar cada una.
Lo que me llevo
- Los tests cambian cómo piensas. Escribir tests primero me obligó a entender el problema antes de tocarlo.
- CI en proyectos de práctica vale la pena. Es poco esfuerzo y mucho retorno en disciplina.
- Java como primer lenguaje serio me dio buenas bases. El tipado estático, las excepciones explícitas y la estructura de clases me forzaron a ser ordenado desde el principio.
- Automatizar métricas del propio repo es formativo. Crear la GitHub Action del badge me enseñó a pensar en el repositorio como un producto, no solo como un almacén de código.
Conclusión
Este repositorio no tiene arquitectura compleja ni funcionalidades llamativas. Pero es el proyecto que mejor refleja mi evolución como programador durante ese periodo: de resolver problemas básicos con dificultad a tener un flujo de trabajo completo con tests, CI y organización.
A veces el proyecto más útil no es el más vistoso, sino el que te obliga a practicar de forma honesta y constante.