Rastreo de autobuses | Transporte público

Contexto

Es el Proyecto Integrador III, hecho en un equipo de cinco. El sistema sigue autobuses en vivo y atiende a tres roles: el pasajero que espera, el conductor al volante y la administración que supervisa la flota.

Aporté la mayor parte de la API y diseñé la interfaz del cliente móvil y del panel web. Mis compañeros los construyeron sobre ese diseño y lo fueron modificando.

Problema

El pasajero de transporte público no sabe cuándo llega su unidad. Espera en la parada sin información, y la única alternativa es un horario publicado que el tráfico altera cada día.

La administración tampoco sabe dónde está su flota mientras opera. Se entera de un retraso cuando alguien lo reporta.

Los tres roles necesitan un dato distinto del mismo viaje, y ninguno lo tenía:

• el pasajero, saber cuándo llega su unidad;
• el conductor, reportar sin distraerse;
• la administración, ver la flota completa a la vez.

Decisiones técnicas

El proyecto empezó con la arquitectura clásica por capas: rutas, controladores, servicios y repositorios. Creció hasta que localizar una funcionalidad exigía abrir cinco carpetas. Reescribirlo entero no era una opción con el curso en marcha y cinco personas más trabajando sobre el mismo repositorio.

La migración fue progresiva y explícita. Cada funcionalidad nueva está en su propio módulo, con su contrato, su implementación, su servicio y su enrutador juntos.

Las capas antiguas se quedaron como adaptadores mínimos hacia esos módulos. Las dos formas se mantienen a propósito, y el repositorio documenta cuál de las dos recibe el código nuevo.

Arquitectura

La telemetría del conductor se emite por canales de difusión y llega al pasajero que sigue esa unidad. Las alertas de proximidad usan canales temporales por usuario, que se suscriben, se usan y se cierran.

Nadie introduce a mano el estado del viaje. Se deriva de la posición en vivo comparada con las paradas de la ruta, así que no depende de que el conductor recuerde marcarlo.

Resultado

La API sirve a los tres roles desde el mismo modelo de datos. El pasajero sigue su unidad, el conductor emite su posición sin operar nada y la administración ve la flota completa.

Dos comprobaciones automáticas protegen el repositorio. Una regla propia del analizador estático rechaza los comentarios en el código. Otra comprobación falla si alguna variable de entorno usada en el código no está declarada en el archivo de ejemplo. Sin ella, ese fallo solo aparece cuando alguien clona el repositorio por primera vez.

Lo que aprendí

Anunciar la arquitectura nueva no bastó, y el equipo siguió escribiendo código en las carpetas antiguas.

Funcionó dejar la forma antigua operativa como adaptador y escribir en el repositorio cuál de las dos recibe el código nuevo. La convención se cumplió cuando quedó escrita donde el equipo trabaja.