Hoy · Hoja de ruta
- 1. Aprende: Qué se revisa en un módulo de JavaScript antes de darlo por terminado.
- 2. Haz: Audita tu proyecto, revisa el de un compañero y corrige.
- 3. Comprueba: Puedes defender cada decisión de tu código.
La lista de auditoría
Auditoría · el código
- No queda ningún
var, y losletson los que de verdad cambian. - Todas las comparaciones usan el triple igual.
- Toda entrada externa se convierte y se valida al leerla.
- Las funciones devuelven valores; imprimir es cosa del principal.
- Ninguna función pasa de veinticinco líneas.
- No hay números sueltos sin nombre.
- Los nombres están en un solo idioma y dicen qué contienen.
- No queda código comentado ni
console.logde depuración.
Auditoría · el comportamiento
- El catálogo vacío no produce
NaNni errores. - Una búsqueda sin resultados devuelve una lista vacía, no
undefined. - Los datos inválidos se rechazan con un mensaje que dice qué falla.
- Ordenar no altera el catálogo original.
- La consola no muestra ningún error al cargar.
Revisión por pares
Intercambia proyectos. Sin preguntar nada a su autor:
- Ejecuta el programa y describe qué hace.
- Elige dos funciones y explícalas en voz alta.
- Búscale tres entradas que lo rompan.
- Señala una cosa bien hecha y una mejorable, con su razón.
Devuelve el trabajo con esas cuatro respuestas por escrito.
Defensa
Prepara respuestas de un minuto para estas cuatro preguntas:
Las preguntas de la defensa
- Enséñame una función y explícame qué recibe, qué devuelve y qué pasa si le llega basura.
- ¿Por qué elegiste ese método de array y no otro?
- Si mañana el catálogo llega desde un servidor en vez de estar escrito en tu fichero, ¿qué tendrías que cambiar?
- Enséñame un fallo que te costó encontrar y cuéntame cómo lo encontraste.
La tercera es la importante, y es la misma pregunta que cerraba la UD1 y la UD2: si has separado datos, lógica y uso, la respuesta debería ser «solo el módulo de datos».
Evaluación
| Criterio | Puntos |
|---|---|
| Tipos y conversión tratados en los bordes del programa | 1,5 |
| Condicionales y bucles que expresan la regla, con sus límites | 1,5 |
| Funciones pequeñas que devuelven en lugar de imprimir | 2 |
| Consultas del catálogo con el método adecuado a lo que se necesita | 2 |
| Modelado con objetos y JSON válido | 1 |
| Módulos con una responsabilidad cada uno | 1 |
| Validación de la entrada y tratamiento de errores | 1 |
No puntúa que el código sea corto ni ingenioso. Puntúa que se pueda leer, que trate los casos raros —la lista vacía, el texto donde esperabas un número— y que puedas cambiar una decisión pequeña delante de alguien.
Entrega
La carpeta js/ con datos.js, catalogo.js, formato.js y main.js; el enlace único con type="module"; la lista de auditoría marcada; la revisión del compañero por escrito; y un fichero NOTAS.md con las tres decisiones que más te costaron y por qué las tomaste así.
Microprueba semanal 6 · 10 minutos
Individual, sin IA y sin apuntes.
- Dado un array de objetos, escribe la consulta que responde a una pregunta con dos criterios y un orden.
- Señala tres señales de que un código necesita refactorizarse.
- Ante un resultado que no es el esperado, ¿qué compruebas y en qué orden?