[Proyecto I]

[mr-sedal]

Nombre: Javier Márquez Zaldívar
Grupo: C-121
Repositorio: https://github.com/mr-sedal/fcbarcelona

Descripción

El proyecto se encarga de gestionar la disponibilidad de los jugadores del FC Barcelona, según sus lesiones, de cara a los partidos de la temporada 25/26, al igual que la planificación de los mismos.

[github-actions]

Verificación Automática — Proyecto I 🤖

Repositorio analizado: https://github.com/mr-sedal/fcbarcelona

1. Repositorio

✅ El repositorio es accesible y fue clonado correctamente.

2. Informe (report.md)

✅ report.md — 2,042 palabras (mínimo: 2,000).

3. Proyecto Python

⚠️ Sin pyproject.toml.
✅ requirements.txt encontrado.

Archivos Python (2, 1,054 líneas en total):

• main.py
• doctor.py

4. Punto de Entrada

✅ Punto de entrada detectado: main.py

5. Ejecución

✅ El proyecto se ejecuta.

Bienvenido, Entrenador. Usted será el encargado de gestionar los partidos de nuestro club.



Operaciones disponibles: 
	1. Solicitar lista de partidos.
	2. Añadir partido.
	3. Eliminar partido.
	4. Modificar detalles de partido.
	5. Guardar y Salir.
Introduzca el número de la operación deseada: Entrada Inválida. Debe digitar un número entre 1 y 5.
Operaciones disponibles: 
	1. Solicitar lista de

Resumen

• ✅ Repositorio accesible
• ✅ report.md con ≥2000 palabras
• ✅ Archivos Python
• ✅ Configuración de dependencias
• ✅ Punto de entrada
• ✅ Ejecución

6/6 verificaciones pasadas.

---

Verificación automática — los resultados son orientativos. El profesor revisará en detalle.

[apiad]

🔍 Revisión de Código — Claude Code

Repositorio: https://github.com/mr-sedal/fcbarcelona

Qué hace tu proyecto

Construiste un gestor de consola del FC Barcelona repartido en dos programas que comparten estado a través de datos.json. En main.py se planifican los partidos de la temporada 25/26: listar con detalle, añadir (rival, fecha, convocatoria de hasta 18 jugadores), eliminar y modificar. En doctor.py se gestionan los lesionados: añadir con tipo de lesión y semanas de baja (calculando la fecha de regreso), quitar y modificar. El modelo recurso/evento es coherente y respeta reglas reales: un partido por fecha, ventana de temporada, tope de 18 convocados y lesionados no convocables.

Ejecución

Corrí ambos programas alimentando entradas por consola desde la raíz del repo. Todo arrancó bien y probé el ciclo completo: añadir/listar/eliminar/modificar partidos, validación de fechas (rechazó 32/13, 30/2, fechas pasadas y fuera de temporada), el detalle de un rival "FC Barcelona", y el flujo de lesionados en doctor.py. Lo más destacado: verifiqué la integración cruzada — lesioné a un jugador en doctor.py y al reabrir main.py el programa avisó y lo quitó automáticamente de un partido donde estaba convocado. Funciona tal como describe tu informe. Los únicos Traceback que vi fueron por fin de entrada en mis pruebas automatizadas, no fallos del programa.

Lo que está bien

• Alcance funcional real: todas las opciones de menú funcionan y la validación de entradas (try/except, rangos, fechas inexistentes) es consistente en ambos programas.
• Integración entre los dos programas: que un cambio en doctor.py se refleje automáticamente en los partidos de main.py es un logro por encima del nivel esperado.
• Persistencia correcta: resolviste bien el problema de guardar fechas en JSON convirtiéndolas a texto y de vuelta; los datos sobreviven entre ejecuciones.
• Nombres de variables y comentarios excelentes: la_fecha_tiene_sentido, cambios_en_disponibilidad y los comentarios por bloque hacen el código legible.

Qué mejorar

• Repites mucho código: el sub-menú para gestionar convocados está escrito casi idéntico dos veces. Muévelo a una función (por ejemplo gestionar_convocatoria(...)) y llámala desde "añadir" y desde "modificar".
• Anidamiento muy profundo: hay bloques con 6-7 niveles de indentación. Extraer funciones también aliviará esto y facilitará encontrar errores.
• Un par de condiciones frágiles en doctor.py: algunos while con condiciones que siempre son verdaderas y un respuesta.strip == "sí" al que le faltan paréntesis. Tú mismo marcaste esa zona como "no está completa" — buena señal; conviene cerrarla.
• Parseo de fechas: en vez de leer la cadena por posiciones, usa datetime.strptime para que sea más robusto.

Sobre el informe

El informe es honesto y coincide con el código: describe con precisión ambos programas, las reglas y la integración cruzada, y documenta con detalle las dificultades reales que resolviste. No infla features inexistentes; incluso es más autocrítico de lo necesario.

Valoración general

Es un trabajo notable y claramente por encima del promedio de un primer proyecto. Tu principal fortaleza es que construiste algo que de verdad funciona de punta a punta, con una integración entre programas que muchos no logran a este nivel. Tu principal área de mejora es aprender a modularizar con funciones para reducir la duplicación y el anidamiento.

---

Revisión automática de código con Claude Code — orientativa. La nota final la pone el profesor.

📄 Reporte detallado (código, archivo y línea): ver análisis completo