Hoy · Hoja de ruta
- 1. Aprende: Qué se evalúa en una defensa técnica.
- 2. Haz: Audita, revisa el proyecto de un compañero y defiende el tuyo.
- 3. Comprueba: Puedes explicar cualquier línea de tu proyecto.
La auditoría final del módulo
Auditoría · la API
- Las rutas se organizan por recursos y son predecibles.
- Cada operación devuelve el código del contrato, también en los errores.
- Todos los errores tienen la misma forma.
- Toda entrada se valida con lista blanca en el servidor.
- Las respuestas no exponen campos internos.
Auditoría · la arquitectura
- Ruta, servicio y repositorio están separados de verdad.
- La aplicación se crea sin arrancarse.
- Cambiar el almacén no toca rutas ni servicio.
- La configuración vive fuera del código y se comprueba al arrancar.
- Los errores se traducen a HTTP en un único sitio.
Auditoría · el conjunto del módulo
- El HTML es semántico y válido, también el generado en el servidor.
- El diseño se adapta y respeta las preferencias del usuario.
- Todo se maneja con teclado y los cambios se anuncian.
- Todo dato ajeno se escapa antes de entrar en la página.
- Las pruebas pasan y detectan las roturas.
- El repositorio no contiene secretos ni dependencias instaladas.
Revisión por pares
Intercambia proyectos y, sin preguntar nada, dedica veinte minutos a:
- Clonar, configurar, sembrar y arrancar. Anota cada tropiezo.
- Usar la aplicación entera solo con el teclado.
- Atacar la API: datos inválidos, campos de más, rutas fuera de lo público, escritura sin clave.
- Ejecutar sus pruebas y romper algo para ver si lo detectan.
- Encontrar dónde vive una regla de negocio y explicarla en voz alta.
La defensa
Tres minutos por persona, mientras el resto sigue con la revisión. Salen cuatro preguntas de esta lista, elegidas al azar, y cubren el módulo entero y no solo esta unidad:
Las preguntas de la defensa final
- Enséñame el recorrido de una petición desde que alguien pulsa un botón hasta que el dato se guarda.
- ¿Por qué esta ruta y no otra? ¿Por qué este código de estado?
- ¿Dónde validas y por qué no basta con hacerlo en el cliente?
- Enséñame una decisión de accesibilidad y explícame a quién ayuda.
- ¿Qué pasa si tu API recibe un campo que no esperabas?
- Si mañana hubiera que cambiar el fichero por una base de datos, ¿qué tocarías?
- Enséñame el fallo que más te costó encontrar y cuéntame cómo lo encontraste.
- ¿Qué harías distinto si empezaras hoy el proyecto?
Las dos últimas valen tanto como las demás: saber qué te costó y qué harías distinto es la prueba de que has entendido lo que hiciste.
Evaluación
| Criterio | Puntos |
|---|---|
| Diseño por recursos y contrato sostenido en toda la API | 1,5 |
| CRUD completo con los códigos de estado del contrato | 1,5 |
| Validación en el servidor, con lista blanca de campos | 1,5 |
| Separación real en rutas, servicio y repositorio | 1,5 |
| Contrato de errores único, usado de punta a punta | 1 |
| Cliente conectado y formularios de extremo a extremo | 1 |
| Configuración por entorno, seguridad mínima y escapado | 1 |
| Pruebas automáticas en verde y aplicación desplegada | 1 |
No puntúa el tamaño del proyecto. Puntúa que el contrato se sostenga: que cada ruta responda lo que promete, que ninguna entrada se crea sin validar y que puedas defender por qué está hecho así.
Entrega final del módulo
El repositorio con la aplicación completa: cliente y API servidos juntos, capas separadas, contrato documentado, configuración por entorno, seguridad mínima y pruebas en verde. La URL del despliegue. El README con sus siete apartados. Las tres listas de auditoría marcadas. La revisión del compañero por escrito. Finalmente, un documento de una página con las tres decisiones técnicas de las que estés más satisfecho y las tres que cambiarías.
Microprueba semanal 6 · 10 minutos
Individual, sin IA y sin apuntes.
- Enumera los cinco puntos que revisarías en una API antes de darla por terminada.
- Explica una decisión de diseño de tu API y una alternativa que descartaste.
- Si mañana el fichero JSON fuera una base de datos, ¿qué tocarías y qué no?