INFOTEP Técnico en Programación de Páginas Web common mistakes
INFOTEP Técnico en Programación de Páginas Web · Understand the traps and how to avoid them.
Confundir el modelo cliente-servidor y afirmar que el navegador ejecuta el código PHP o que el servidor renderiza el HTML antes de enviarlo, sin distinguir qué ocurre en cada extremo.
Se estudia la arquitectura de forma memorística, sin asociar cada tecnología a su entorno de ejecución; además, el término 'renderizado' se usa de forma ambigua y se mezcla con el procesamiento del lado del servidor.
What to do instead
Elaborar una tabla de dos columnas (cliente/servidor) y clasificar en ella cada tarea: interpretar HTML/CSS, ejecutar JavaScript, procesar formularios, consultar la base de datos, generar respuestas dinámicas. Repetir el ejercicio con un flujo completo de petición HTTP y respuesta. Verificar cada afirmación preguntándose '¿qué máquina ejecuta esto?'.
Usar <div> y <span> para todo, sin emplear etiquetas semánticas como <header>, <nav>, <main>, <article>, <section> o <footer>, y omitir atributos de accesibilidad como alt en imágenes o etiquetas asociadas a los campos de formulario.
Se prioriza que la página 'se vea bien' sobre su estructura; muchos tutoriales antiguos muestran maquetación con divs y no se practica la semántica ni la accesibilidad en ejercicios reales.
What to do instead
Antes de escribir CSS, esbozar el esquema de la página y asignar a cada bloque su etiqueta semántica. Revisar cada imagen (alt descriptivo o alt="" si es decorativa), cada input (con o aria-label) y cada botón (texto o aria-label). Validar con el validador del W3C y con una comprobación de accesibilidad automatizada, y corregir los avisos.
Maquetar con posicionamiento absoluto y anchos fijos en píxeles, sin usar Flexbox, Grid ni media queries, y afirmar que una web es responsive solo porque tiene un viewport meta.
El posicionamiento absoluto da resultados inmediatos en el escritorio y evita comprender el flujo normal del documento; además, se confunde la etiqueta viewport con la adaptación real del diseño.
What to do instead
Construir primero la estructura en flujo normal y luego aplicar Flexbox o Grid para la distribución. Definir puntos de ruptura con media queries (por ejemplo, 480 px, 768 px, 1024 px) y probar el resultado redimensionando la ventana y con las herramientas de dispositivo del navegador. Comprobar que no aparecen barras de desplazamiento horizontal y que los textos no se solapan.
Explicar el bucle de eventos de JavaScript diciendo que setTimeout(fn, 0) se ejecuta antes que una promesa resuelta, o que una función async se ejecuta de forma síncrona hasta el primer await sin ceder el control.
Se aprende la asincronía con ejemplos superficiales y no se distinguen la pila de llamadas, la cola de microtareas (promesas) y la cola de macrotareas (temporizadores, eventos).
What to do instead
Escribir y ejecutar pequeños programas que registren el orden de ejecución con console.log, incluyendo promesas, setTimeout y await, y predecir la salida antes de ejecutarla. Dibujar el recorrido de cada tarea entre la pila de llamadas y las colas. Repetir hasta interiorizar que las microtareas se vacían antes de la siguiente macrotarea.
Manipular el DOM con innerHTML usando datos introducidos por el usuario, o concatenar cadenas para construir consultas SQL en el servidor, sin escapar ni parametrizar.
Es la forma más rápida de obtener un resultado visible y muchos ejemplos introductorios la emplean; no se ha interiorizado que toda entrada del usuario es no confiable.
What to do instead
Sustituir innerHTML por textContent o createElement cuando el contenido no sea HTML de confianza. En el servidor, usar siempre consultas parametrizadas o sentencias preparadas y validar la entrada en el servidor, no solo en el cliente. Revisar el código buscando concatenaciones con variables en consultas y en inserciones en el DOM, y corregirlas antes de dar la tarea por terminada.
Diseñar tablas sin clave primaria, guardar listas de valores en una sola columna separada por comas o duplicar datos en varias filas, y luego no saber explicar por qué se produce una anomalía de actualización.
Se modela pensando en la pantalla que se quiere mostrar y no en las entidades y sus relaciones; además, no se practica la normalización con datos reales.
What to do instead
Identificar entidades y relaciones antes de escribir SQL, asignar una clave primaria a cada tabla y crear tablas intermedias para relaciones muchos a muchos. Aplicar las formas normales (1FN, 2FN, 3FN) a un esquema propio y comprobar con ejemplos de inserción, actualización y borrado que no se pierde ni se duplica información. Documentar el diagrama entidad-relación resultante.
Trabajar con Git haciendo commits de todo el proyecto a la vez, sin ramas, y resolver un conflicto de fusión aceptando una de las dos versiones sin revisar el resultado.
Se usa Git como copia de seguridad y no como herramienta de colaboración; los conflictos se perciben como errores que hay que eliminar rápido en lugar de como una decisión que debe revisarse.
What to do instead
Adoptar un flujo con ramas por funcionalidad, commits pequeños con mensajes descriptivos y revisiones antes de fusionar. Ante un conflicto, abrir el archivo, leer las marcas de conflicto, decidir qué código se conserva (a menudo una combinación de ambos cambios), eliminar las marcas y ejecutar las pruebas antes de confirmar la fusión.
Responder que HTTPS cifra el sitio y lo hace seguro por sí solo, o afirmar que validar el formulario en JavaScript sustituye a la validación en el servidor.
Se confunde el cifrado en tránsito con la seguridad de la aplicación y se asume que el navegador es un entorno de confianza; además, no se distingue entre autenticación, autorización y cifrado.
What to do instead
Separar los conceptos: HTTPS protege la comunicación, pero no evita inyecciones ni accesos indebidos. Repasar la lista de riesgos habituales (inyección SQL, XSS, CSRF, contraseñas en texto plano) y, para cada uno, indicar la medida concreta (consultas parametrizadas, escape de salida, tokens anti-CSRF, hash con sal). Repetir la validación siempre en el servidor y usar la del cliente solo como mejora de la experiencia.
Publicar el sitio subiendo archivos por FTP sin comprobar rutas relativas, sin revisar la consola del navegador y sin verificar que las variables de entorno y las credenciales no quedaron expuestas en el repositorio.
Se prueba solo en local con rutas absolutas o con el servidor de desarrollo, y no se realiza una comprobación posterior al despliegue; las prisas por publicar llevan a omitir la revisión.
What to do instead
Antes de publicar, usar rutas relativas, revisar que .env y archivos de configuración estén en .gitignore y comprobar la consola y la pestaña de red en el sitio desplegado. Tras el despliegue, recorrer las páginas principales, verificar enlaces, formularios y errores 404, y documentar el procedimiento de publicación y reversión para poder repetirlo.
Entregar el proyecto sin documentación técnica ni control de cambios: sin README con instrucciones de instalación, sin descripción de la estructura de carpetas y sin registrar las decisiones tomadas durante el desarrollo.
Se considera que el código 'habla por sí solo' y se deja la documentación para el final, cuando ya no queda tiempo; además, no se ha practicado la redacción de documentación técnica durante el curso.
What to do instead
Escribir el README al inicio del proyecto con objetivo, requisitos, instalación, ejecución y estructura de carpetas, y actualizarlo en cada entrega. Mantener un registro breve de decisiones y cambios (por ejemplo, en un archivo CHANGELOG o en las descripciones de los commits) y revisar al cierre que cualquier persona pueda poner en marcha el proyecto siguiendo solo la documentación.