Avanzado
Unas 30 horasProyecto 4 de 4Rescate de código heredado: pruebas, refactorización, documentación y CI
Una academia usa un programa de consola escrito hace años por un alumno en prácticas: un único fichero de 600 líneas con métodos enormes, nombres de una letra y números mágicos. Tu misión es dejarlo mantenible sin cambiar su comportamiento: protegerlo con pruebas, refactorizarlo paso a paso, documentarlo y automatizar su comprobación.
Java 21GitJUnit 5Checkstyle y PMDJavadocPlantUMLGitHub Actions
Tu avance0/20 · 0 %
Objetivos de aprendizaje
- •Proteger código sin pruebas con pruebas de caracterización
- •Aplicar refactorizaciones con las herramientas del IDE en pasos pequeños y seguros
- •Detectar malos olores con analizadores de código
- •Documentar con Javadoc y diagramas UML generados desde el código
- •Automatizar compilación, análisis y pruebas en integración continua
Requisitos mínimos
Fases sugeridas
- 1
Red de seguridad
- 2
Refactorización
- 3
Documentación
- 4
Automatización
Qué entregar
- Repositorio con historial de commits y pull requests
- Informe de refactorizaciones con el antes y el después de los analizadores
- Documentación Javadoc y diagramas
- Enlace a la última ejecución correcta de la integración continua
Para ir más allá
- Mide la complejidad ciclomática antes y después
- Añade pruebas de mutación al flujo
- Publica la documentación con GitHub Pages
Rúbrica de evaluación
| Criterio | Peso | Para la máxima nota |
|---|---|---|
| Comportamiento conservado | 20 % | Las pruebas de caracterización pasan en todos los commits |
| Refactorizaciones | 30 % | Variadas, justificadas por un olor concreto y hechas en pasos pequeños |
| Calidad final | 15 % | Analizadores sin avisos relevantes y diseño claramente mejor |
| Documentación | 15 % | Javadoc útil (contrato, excepciones) y diagramas coherentes con el código |
| Integración continua y Git | 20 % | Flujo en verde, ramas protegidas y pull requests revisados |
Úsala para autoevaluarte antes de entregar. Tu profesorado puede usar otros criterios.
Consejos y errores típicos
- Nunca mezcles una refactorización con un cambio de funcionalidad en el mismo commit.
- Si no entiendes un bloque, primero escribe una prueba que fije lo que hace; después cámbialo.
- Usa las refactorizaciones automáticas del IDE: son más seguras que editar a mano.