Muéstrale el monolito a Devin
Conoces ese archivo: un único router de Express que ha ido creciendo durante dieciocho meses. Todos los endpoints de cada dominio viven en Dile a Devin exactamente cómo quieres que se vea la estructura objetivo.
src/routes/index.ts: el registro de usuarios junto a los webhooks de pagos junto a la búsqueda de productos. Las comprobaciones de autenticación incrustadas en el código están copiadas y pegadas en 40 controladores. Nadie quiere tocarlo porque un cambio en la lógica de pedidos podría romper los endpoints de usuario trescientas líneas más arriba.Así es como suele verse la parte superior del archivo:src/routes/index.ts (before — 2,000 lines)
Guía a Devin con convenciones
Devin lee tu base de código para inferir patrones, pero la refactorización es donde las entradas de Knowledge aportan más valor. Agrega entradas para las convenciones que Devin debe seguir:
- Patrones de router — “Cada router de dominio usa
Router()y se monta conapp.use('/domain', domainRouter)en la raíz” - Middleware — “El middleware de autenticación vive en
src/middleware/y siempre se importa, nunca se define en línea” - Manejo de errores — “Todos los manejadores de rutas usan nuestro wrapper
asyncHandlerdesrc/lib/asyncHandler.ts— nunca un try/catch directo”
src/routes/admin.ts, que ya está claramente separado” a tu prompt.También puedes pedirle a Devin que genere entradas de Knowledge para ti: solo describe tus convenciones y creará entradas bien estructuradas que podrás revisar y guardar.Revisar el PR de Devin
Devin mapea todos los endpoints, sigue el grafo de imports, extrae la lógica compartida, crea los archivos de dominio, reconfigura el router raíz y ejecuta tu suite de pruebas. Así es como suele verse el PR:Así queda el router raíz limpio después de la división:Y un archivo de rutas de dominio donde se importa correctamente el middleware compartido:Cada ruta de URL permanece igual:
src/routes/index.ts (after — 15 lines)
src/routes/orders.ts (after — excerpt)
/orders ahora es gestionada por ordersRouter, montado en /orders, por lo que los clientes y las pruebas existentes funcionan sin necesidad de cambios.(Opcional) Haz checkout de la rama y prueba localmente
Para una refactorización estructural como esta, vale la pena hacer checkout de la rama y verificarla localmente antes de fusionarla. Pruébala en Windsurf o en tu IDE preferido, levanta la aplicación y prueba algunos endpoints para confirmar que el enrutamiento, el middleware y el manejo de errores se comportan igual que antes.Si ves algo raro, deja un comentario en el PR: Devin lo verá y subirá una corrección.
