[Proyecto I] Editor Liga de Futbol

[Alec-As]

Nombre: Alec Quiñones Romero
Grupo: C-122
Repositorio: https://github.com/Alec-As/Editor_Liga_de_Futbol

Descripción

Organizar una liga de fútbol no es solo poner fechas en un calendario. Es un rompecabezas logístico donde cada decisión afecta a todo el sistema. Este proyecto nace de esa necesidad: automatizar la planificación respetando todas las restricciones que una liga real impone.

• Recursos limitados: Vehículos, árbitros, médicos, seguridad... todo tiene un costo y disponibilidad.
• Descansos obligatorios: Los equipos no pueden jugar todos los días.
• Capacidad de estadios: No todos los equipos pueden alojarse en el mismo lugar.
• Reglas de competición: Cada equipo debe jugar de local al menos una vez, y no pueden repetirse enfrentamientos sin control.

El sistema se encarga de validar cada solicitud antes de registrarla, garantizando que el calendario siempre sea consistente y realista.

[apiad]

🔧 Título corregido al formato [Proyecto I] para disparar la verificación automática.

/revisar

[github-actions]

Verificación Automática — Proyecto I 🤖

Repositorio analizado: https://github.com/Alec-As/Editor_Liga_de_Futbol

1. Repositorio

✅ El repositorio es accesible y fue clonado correctamente.

2. Informe (report.md)

⚠️ report.md encontrado pero con solo 833 palabras (mínimo: 2,000).

3. Proyecto Python

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

Archivos Python (7, 1,276 líneas en total):

• Task.py
• GUI.py
• Manager.py
• Teams_and_Stadiums.py
• Time.py
• Resource.py
• main.py

4. Punto de Entrada

✅ Punto de entrada detectado: main.py

5. Ejecución

✅ El proyecto se ejecuta.

Traceback (most recent call last):
  File "/tmp/tmpb8r311ix/repo/main.py", line 4, in <module>
    main()
  File "/tmp/tmpb8r311ix/repo/GUI.py", line 450, in main
    root = tk.Tk()
           ^^^^^^^
  File "/opt/hostedtoolcache/Python/3.12.13/x64/lib/python3.12/tkinter/__init__.py", line 2346, in __init__
    self.tk = _tkinter.create(screenName, baseName, className, interactive, wantobjects, us

Resumen

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

4/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/Alec-As/Editor_Liga_de_Futbol

Qué hace tu proyecto

Construiste un planificador de una liga de fútbol con interfaz gráfica (Tkinter): registras partidos y viajes entre 10 equipos y 10 estadios, y el sistema valida cada solicitud contra un conjunto de restricciones acopladas —descansos entre tareas, capacidad de estadios, disponibilidad de recursos (vehículos según distancia, árbitros/médicos/seguridad por partido) y reglas de localía. Lo más valioso es que calculas la ubicación de cada equipo dinámicamente a partir de su último viaje: esa es la idea que hace que todo lo demás funcione. Es un dominio genuinamente complejo y lo modelaste con criterio.

Ejecución

Tu proyecto no es de consola, es una GUI, así que no lo alimenté con printf. Intenté arrancar la ventana directamente y bajo un framebuffer virtual (xvfb), pero aborta con un error de X11/xcb (Aborted, core dumped) — es un problema del entorno de ejecución, no de tu código (es el mismo fallo que reportó la verificación automática del issue en tk.Tk()). Todos tus módulos compilan sin error.

Como separaste muy bien la lógica de la GUI, pude ejecutar tu LeagueManager directamente con datos reales y recorrer muchos flujos válidos e inválidos. Eso me dio una imagen precisa de qué funciona y qué no.

Lo que está bien

• Arquitectura limpia: toda la lógica vive en LeagueManager y la GUI solo llama a métodos que devuelven {"success", "message"}. Ese contrato uniforme es una práctica excelente — es literalmente lo que me permitió probar tu lógica sin abrir la ventana.
• Las validaciones funcionan de verdad (todo verificado ejecutando): rechazo de mismo-equipo, la co-ubicación para la localía ("no se encuentra en el mismo estadio"), el descanso de 3 días entre partidos, el control de enfrentamientos repetidos con played_against, y la capacidad de estadio (al Camp Nou, cap 2, le permite 2 viajes y rechaza el tercero).
• Tu aritmética de fechas es robusta: probé casos límite y todos salieron bien — 28/2/2024 +1 = 29/02 (bisiesto correcto), cruce de mes hacia atrás (15/6 −20 = 26/05), y los topes en 31/12 y 1/1. Muy bien resuelto.
• Jerarquías de clases con propósito (Task→Match/Travel, Resource→Vehicle/Instrument_Personal) y buen manejo de excepciones al cargar (FileNotFoundError, JSONDecodeError).

Qué mejorar

• Bug importante: save_state solo guarda la última fecha del calendario. Lo reproduje: con 3 fechas en memoria, el JSON guardado contenía solo 1 — se perdieron las otras 2 silenciosamente. La causa es de indentación en Manager.py:509-511: las líneas tasks_list.append(task_dict) y state["schedule"][date_str] = tasks_list quedaron fuera de sus bucles for. Muévelas hacia adentro (la primera dentro del for task, la segunda dentro del for date_str) y tu Guardar/Cargar conservará todo el calendario. El league_state.json de tu repo, con una sola fecha, es síntoma de esto.
• Falla ruidosamente, no en silencio. Cuando llega una fecha inválida como el 31 de febrero, la "arreglas" convirtiéndola en 1/1 (Time.py:7-10) sin avisar. Para un editor que promete "validar cada solicitud", sería más coherente rechazarla y avisar al usuario, igual que haces con las demás restricciones.
• Asignación de vehículos subóptima: para un viaje de 500 km asignaste 5 Vans (5×100) en vez del Avión (1×500), agotando toda la flota de vans. Ordenas por alcance ascendente (Manager.py:169) y llenas con los pequeños primero. Considera probar primero el vehículo cuyo alcance cubra el trayecto en menos unidades.
• _days_between ignora el año (Manager.py:262-269): da 0 entre 1/1/2024 y 1/1/2025. Hoy no te afecta porque todo es 2024, pero se rompería con temporadas que crucen de año. Fácil de blindar sumando los días de los años completos.
• Detalle idiomático: str(task) en vez de task.__str__(), e importar nombres explícitos en vez de from X import *.

Sobre el informe

El informe describe fielmente lo que el código hace (las tablas de equipos, estadios y recursos coinciden exactamente) y no inventa features. Dos matices: (1) decir que los recursos "se asignan de forma inteligente" es generoso dado que la heurística de vehículos es subóptima; (2) la regla "dos equipos solo pueden jugar dos veces y al menos una de local" está enunciada más fuerte de lo que el código realmente garantiza — controlas que no se repita el enfrentamiento en una dirección, pero no aseguras el partido de vuelta. Además está por debajo del mínimo de palabras y le falta una sección de diseño (por qué esas clases, cómo calculas la ubicación de un equipo, qué invariantes mantienes) — justo lo que subiría su valor técnico. En conjunto: un trabajo ambicioso, bien estructurado y que funciona; corrige el bug de save_state y estarás muy bien. ¡Buen trabajo!