[Proyecto I] Arlenis #334

Activity

1. github-actions commented on Jul 12, 2026

   

   github-actionsbot

   on Jul 12, 2026 – with GitHub Actions

   More actions

   Verificación Automática — Proyecto I 🤖

   ❌ No se encontró una URL de repositorio de GitHub en el Issue.

   Por favor asegúrate de incluir el enlace completo en el campo Repositorio, por ejemplo:
   https://github.com/tu-usuario/tu-proyecto
2. apiad commented on Jul 16, 2026

   

   apiad

   on Jul 16, 2026

   Member

   More actions

   🔍 Revisión de Código — Claude Code

   Repositorio: https://github.com/betancourtarlenisroxana-code/Gestor

   Qué hace tu proyecto

   Hiciste un Gestor de Bodas que registra locales y bodas, comprueba que un local no se solape en fechas con otra boda ya reservada, y guarda todo en archivos JSON para recuperarlo la próxima vez. El corazón del proyecto — la carpeta Gestor de Bodas/ con models/, manager/ y persistence/ — está muy bien organizado para primer año, y la persistencia de datos es de lo más completo que suele verse a este nivel.

   Ejecución

   Corrí de verdad la versión de consola (Gestor de Bodas/main.py) con Python 3.12, alimentando el menú con entradas simuladas. El flujo completo funciona: creé el local "Salon Real" (capacidad 100), creé una boda para "Maria Lopez" con fechas válidas, la listé y salí guardando. Todo devolvió Local creado, ✅ Boda añadida correctamente y 💾 Datos guardados. Al relanzar el programa, la boda guardada se cargó sola desde el JSON y volvió a aparecer: tu round-trip de persistencia funciona en los dos sentidos. También probé crear una segunda boda solapada y el sistema la rechazó con ❌ El local ya está ocupado en esas fechas. Los 12 módulos compilan sin errores.

   La interfaz Tkinter (interfaz/ventana.py) no pude arrancarla porque este entorno no tiene pantalla gráfica (fallo de X11, no de tu código), pero revisé su lógica: el parseo de fechas rechaza correctamente formatos inválidos.

   Lo que está bien

   • Modularidad real: separaste modelos, persistencia, gestor y menú en carpetas distintas, con una clase por archivo y __str__ en todas. Eso es diseño de proyecto de nivel.
   • Persistencia bidireccional verificada: guardas y recuperas locales y bodas, e incluso reconstruyes la relación entre cada boda y su local buscándolo por nombre (persistence/storage.py:91-94). Muy bien pensado.
   • Detección de solapamiento de fechas en manager/manager.py:16-25: una comprobación con valor real, no de adorno.
   • El menú no se cae si escribes una opción que no es número, porque comparas texto en vez de convertir a int. Buena decisión.

   Qué mejorar

   • Protege TODAS las entradas de main.py. Ahora mismo, si escribes una fecha mal (fecha-mala) o una capacidad no numérica (abc), el programa revienta con un Traceback (main.py:16 y main.py:36). Lo mismo pasa con capacidad ≤ 0. Envuelve cada int(input(...)) y datetime.fromisoformat(input(...)) en un try/except ValueError que vuelva a pedir el dato. Ya lo hiciste bien en la GUI (ventana.py:166), replica esa idea en la consola.
   • El repo tiene tres proyectos mezclados. Está la versión de consola buena (Gestor de Bodas/), la GUI aislada, y un prototipo viejo (programacion/main.py + menu.py) con código a medio hacer (os.system("cls") solo va en Windows, y agregar_boda está roto). Elige cuál es tu entregable, bórra el resto y así queda clarísimo qué evaluar.
   • La GUI no está conectada con tus clases buenas. En interfaz/ventana.py:6-27 vuelves a definir Cliente, Local, Boda en vez de importar las de models/. Si en el futuro la integras de verdad (from models.local import Local), aprovecharías toda la validación y persistencia que ya escribiste.
   • Manager tiene dos __init__ (manager/manager.py:9 y :31). Python solo se queda con el segundo; fusiónalos en uno.
   • Tu menú de consola no da acceso a agregar_invitado, pedir_bebida ni asignar_asiento, aunque los programaste en models/boda.py. Esa funcionalidad existe pero el usuario no puede llegar a ella: añade opciones al menú para usarla.

   Sobre el informe

   El README está bien escrito, pero describe un programa algo distinto al que se ejecuta, y conviene alinearlo:

   • Presenta la interfaz gráfica como el eje del proyecto y dice que está "conectada directamente con las clases". En realidad la app que funciona es de consola, y la GUI está desconectada de models/.
   • Dedica una sección entera a una "clase Bebidas" que no existe: las bebidas son un simple diccionario dentro de Local.
   • La estructura que dibuja el informe omite manager/ y persistence/, que son justamente tus partes más fuertes; incluye ese trabajo en el informe.

   En resumen: tienes un núcleo de consola sólido y bien pensado, con una persistencia muy por encima de lo habitual en primer año. Ordena el repo, blinda las entradas y ajusta el informe al programa real, y quedará un proyecto redondo. ¡Buen trabajo con la organización y el guardado de datos!
3. apiad

   added a commit that references this issue on Jul 16, 2026

   docs(reviews): add Proyecto I code reviews (batch 11: #325-#334)

   ...

   5b373d2