Cada revisor pide cosas distintas
Compruebo que, sin reglas escritas, lo que un revisor aprueba otro lo rechaza. La revisión depende de quién la haga ese día y genera fricción sin mejorar la calidad.
Moodle · Ingeniería
Calidad de código en Moodle: qué revisar y cómo comprobarlo
Una demostración solo me confirma que un recorrido funciona en esas condiciones. Para decidir si un desarrollo se puede mantener, reviso otras seis cuestiones: qué interfaces de la plataforma usa, si comprueba los permisos en cada punto de entrada, cómo se comporta al aumentar el volumen, si declara los datos personales que guarda, qué ocurre al restaurar un curso que lo use y si seguirá funcionando en la siguiente versión. Si no escribo esas preguntas de antemano, convierto la revisión en una negociación entre mis preferencias y las prisas de quien entrega. Defino reglas explícitas y automatizo las comprobaciones que admiten automatización; así sustituyo la discusión por una comprobación.
- La plataforma publica un estándar de código y herramientas oficiales para verificarlo automáticamente.
- No conviene gastar atención humana en lo que una máquina puede comprobar.
- Las reglas se acuerdan antes de escribir el código, no se descubren al revisarlo.
- La seguridad, la privacidad, el comportamiento con carga y la compatibilidad no se evalúan comprobando solo que el resultado sea correcto.
Experiencia en ingeniería
Reviso el estándar de código, el análisis estático, la validación de parámetros, los permisos y la seguridad de cada punto de entrada. Compruebo también el comportamiento con más volumen, la privacidad, la copia y restauración y la compatibilidad con las versiones objetivo.
Mi trayectoriaCómo detecto que falta criterio al revisar
Identifico cuatro señales claras.
Las revisiones son un visto bueno rápido
Compruebo que los revisores aprueban por falta de tiempo y porque no tienen claro qué deben mirar. La revisión figura en el proceso, pero no filtra nada.
Encuentro problemas en producción
Busco problemas como permisos que faltan, consultas lentas y datos que no se restauran. Parte de esos riesgos deja señales en el código. Para detectar los demás, uso datos representativos, hago una restauración y recojo mediciones del entorno. Nadie los buscó porque no figuraban en ninguna lista.
Aceptamos y pagamos el trabajo de los proveedores
Sin criterios técnicos de aceptación, solo compruebo el funcionamiento. No reviso lo que no veo funcionar.
Las seis dimensiones de una revisión seria
Automatizo casi por completo las dos primeras. En las cuatro últimas aplico mi conocimiento de la plataforma.
- 01
Estándar de código
Compruebo automáticamente con las herramientas oficiales el formato, la estructura, la documentación obligatoria y las funciones prohibidas. Reviso a mano la claridad de los nombres, la cohesión, las decisiones de diseño y las excepciones justificadas.
- 02
Análisis estático
Compruebo los tipos, las rutas de ejecución imposibles, las variables sin definir y los errores visibles sin ejecutar el código. Una vez configurada, esta comprobación tiene un coste de ejecución bajo; su implantación inicial depende del volumen y del estado del código existente.
- 03
Seguridad y permisos
Compruebo el contexto y la capacidad en cada punto de entrada, valido los parámetros recibidos, escapo la salida y uso consultas con parámetros. Un fallo aquí puede convertirse en una vulnerabilidad; lo analizo según la entrada, el alcance y el efecto.
- 04
Comportamiento al aumentar el volumen
Localizo consultas dentro de bucles, índices que conviene comprobar, cargas completas en memoria y trabajo pesado dentro de la petición. Confirmo su efecto con datos representativos, planes de ejecución, perfiles de carga y medidas del entorno.
- 05
Privacidad, copia y restauración
Compruebo que la extensión declare los datos personales que trata e implemente las operaciones de privacidad correspondientes. También verifico que integre esos datos en las API de copia y restauración cuando formen parte de un curso o una actividad y el traslado exija conservarlos.
- 06
Compatibilidad futura
Compruebo que el código use solo interfaces públicas, no haga llamadas marcadas como obsoletas ni dependa de comportamientos internos. Con ese análisis determino si la próxima actualización requerirá una revisión o un proyecto.
Lo que encuentro una y otra vez
Seis cosas que he encontrado revisando código que ya había pasado una revisión.
Puntos de entrada sin comprobación de permisos
Compruebo por separado el acceso a la página y al punto que recibe los datos. Si este último no lo comprueba, detecto el fallo al llamarlo directamente.
Parámetros sin validar
No doy por hecho que lo recibido tenga el formato esperado. Valido cada parámetro según su tipo y su uso antes de procesarlo. Sin esa validación, puede ampliar la superficie de ataque y permitir que datos inesperados alcancen consultas, rutas de ejecución o salidas sensibles.
Salida sin escapar
He detectado este fallo: un dato introducido por una persona se muestra sin el escapado adecuado. Lo descubro cuando alguien introduce marcado o código que el navegador interpreta; hasta entonces, todo parece funcionar.
Consultas construidas por concatenación
Paso los datos de entrada como parámetros, porque incorporarlos por concatenación puede cambiar el sentido de la consulta y abrir una inyección. Construyo los fragmentos estructurales que no admiten parámetros con opciones permitidas o con las interfaces de Moodle.
Datos personales que la gestión de privacidad no cubre
La extensión guarda información de personas que las herramientas de exportación y borrado no ven. Es un incumplimiento silencioso.
Llamadas a elementos marcados como obsoletos
En la revisión señalo lo que funciona hoy aunque esté anunciado que dejará de funcionar. Si nadie lo señala, lo considero deuda contraída a sabiendas.
Lista de revisión de un desarrollo para Moodle
La que aplico yo. Las cuatro primeras son bloqueantes siempre.
- Cada punto de entrada establece el contexto y aplica la comprobación de acceso que corresponda. Si no exige autenticación o una capacidad concreta, la decisión queda justificada y se revisan las protecciones equivalentes.
- Todos los parámetros recibidos se validan con el tipo esperado.
- Todo dato que no sea de confianza se valida al recibirlo y se escapa al mostrarlo con la función adecuada al contexto de salida; cualquier saneamiento adicional se aplica cuando el caso lo exige.
- Todos los valores variables se pasan mediante parámetros. Los fragmentos estructurales dinámicos solo se construyen cuando no pueden parametrizarse, a partir de opciones permitidas o de las API de Moodle, y quedan justificados y cubiertos por pruebas.
- Las consultas repetidas dentro de bucles se agrupan cuando es posible; las excepciones quedan justificadas y medidas. La carga de datos en memoria se limita al volumen previsto.
- Los datos personales están declarados en la interfaz de privacidad.
- Cuando corresponde por el tipo de extensión y por sus datos, la copia y la restauración conservan la información necesaria.
- No se usan funciones internas ni marcadas como obsoletas.
- El estándar de código lo verifica una herramienta, no una persona.
- La lógica propia tiene pruebas automatizadas que fallan si se rompe.
Qué decido antes de revisar
Uso cinco acuerdos para convertir la revisión en una comprobación, no en una opinión.
- 01
¿Qué comprobaciones automatizo y cuáles hago personalmente?
Reparto el trabajo: resuelvo el estándar y el análisis estático antes de que nadie lea el código. Así evito que el revisor gaste su atención en lo barato.
- 02
¿Qué convierte un hallazgo en bloqueante?
Seguridad y pérdida de datos siempre lo son. El resto lo gradúo porque, si no, la revisión termina en una lista infinita que nadie aplica.
- 03
¿Cuándo considero terminado un trabajo?
Considero terminado un trabajo cuando incluye código, pruebas y documentación de la decisión, y cuando he comprobado la copia y la restauración. Si solo compruebo que funciona, dejo todo lo demás sin hacer.
- 04
¿Quién revisa lo que entrega un proveedor?
No considero útiles los criterios de aceptación del contrato si nadie de la organización puede juzgar si se cumplen.
- 05
¿Qué hago con lo que ya está en producción?
Si aplico reglas nuevas solo a lo nuevo, dejo intacto el problema heredado. Decido si reviso lo existente y con qué prioridad.
Tres formas de revisar con las que no evito los problemas
Con las tres, pierdo tiempo y obtengo una falsa sensación de control.
No reviso solo el resultado funcional
Reviso también la seguridad, el rendimiento, la privacidad y la compatibilidad. Comprobar solo que la pantalla hace lo que decía el requisito deja fuera todo lo que se paga después.
No discuto cuestiones de estilo en la revisión humana
Automatizo la comprobación de la indentación y los nombres. Dedicarles la atención de dos personas consume tiempo en lo barato y no deja tiempo para lo caro.
No confío en que el análisis automático baste
Detecto con herramientas automáticas los incumplimientos del estándar y ciertos riesgos que siguen patrones repetibles, pero no dejo en sus manos el juicio sobre las decisiones de diseño. Aunque el código cumpla todas las reglas de estilo, puede consultar la base de datos dentro de un bucle.
Qué cambia según el equipo
Mantengo el proceso proporcionado; de lo contrario, el equipo lo abandona.
- Una persona desarrolla
Compruebo automáticamente el estándar y uso una lista de comprobación propia. Como no cuento con revisión por pares, doy más peso a la automatización.
- Equipo pequeño
Exijo una revisión cruzada, aplico reglas escritas y ejecuto un análisis automático en cada cambio. Así reparto el criterio entre varias personas.
- Varios equipos o proveedores
Publico las reglas, aplico las mismas a todos y compruebo automáticamente cada entrega antes de aceptarla.
- Plataforma crítica
Añado a lo anterior una revisión específica de seguridad, pruebas de carga sobre lo nuevo y una revisión independiente periódica.
Qué requisitos de calidad exigir en un contrato
Sin estas filas, «código de calidad» no significa nada exigible.
| Requisito | Evidencia exigible | Criterio de aceptación |
|---|---|---|
| Cumplimiento del estándar de la plataforma | Informe de la herramienta oficial de verificación | Sin incumplimientos en el código entregado |
| Análisis estático ejecutado | Informe del análisis estático con el nivel fijado | Sin incidencias de gravedad alta |
| Revisión de seguridad | Compruebo los permisos, la validación, el escapado y las consultas | Sin hallazgos de seguridad pendientes |
| Declaro cómo gestiono la privacidad y las copias de seguridad | Implementación de las interfaces correspondientes | Exportación, borrado y restauración funcionan sobre sus datos |
| Sin llamadas obsoletas | Revisión de compatibilidad con la versión de destino | Ninguna llamada marcada como obsoleta en el código nuevo |
Referencias
Fuentes y límites
- Documentación oficialGuía de estilo de código — documentación oficial
Estándar completo y herramientas oficiales de verificación que recomienda usar de forma combinada. Consultado el 1 de agosto de 2026.
- Documentación oficialDirectrices de seguridad — documentación oficial
Comprobación de permisos, validación de entrada, escapado de salida y consultas con parámetros. Consultado el 1 de agosto de 2026.
- Documentación oficialInterfaz de privacidad — documentación oficial
Obligaciones de una extensión que almacena datos personales. Consultado el 1 de agosto de 2026.
El reparto entre lo que comprueba la máquina y lo que comprueba una persona es criterio propio, igual que la clasificación de qué hallazgos son bloqueantes: dependen del riesgo que asuma cada organización. Las reglas técnicas concretas están en la documentación oficial enlazada y cambian entre versiones. Las herramientas de análisis que uso en mi trabajo son propias y están documentadas en las fichas de trabajo, sin datos de organizaciones concretas.
Blog
Casos, pruebas y fuentes.
En el blog desarrollo revisiones de código con reglas, ejemplos y fuentes técnicas que no caben en esta lista de comprobación.
Ir a blog.albertolarah.comContacto
Con qué criterios evalúo un desarrollo
Aplico la misma lista al código propio pendiente de revisión y a una entrega de proveedor pendiente de aceptación. Antes identifico qué hace la extensión, quién la construyó, si hay pruebas y si existen criterios de aceptación escritos.
hola@albertolarah.comLinkedIn ↗