6.3Buenas prácticas y trampas
Lo esencial en 30 segundos
- Regla de oro : código limpio, desconfianza sistemática hacia las entradas, estructura y entrega — la seguridad paga, nunca la velocidad bruta.
- Hacer : === y strict_types, consultas preparadas + escape, MVC + Composer, password_hash + .env, PHPUnit, medir y luego entregar.
- Evitar : concatenación SQL, visualización en bruto, secretos en claro, solo validación de cliente, pruebas descuidadas, errores expuestos.
Hilo Riad — tres hábitos que pagan
Tras un año, Riad hace su balance : lo que más contó no es un framework, sino tres hábitos — comparar en estricto y tipar, preparar cada consulta y escapar cada visualización, y entregar hasta el final con pruebas y despliegue. Y su mayor trampa evitada por poco : una contraseña guardada en claro durante una semana de rush.
Elige un solo hábito para fijar en tu ritual, luego pasa al siguiente.
Lo que marca la diferencia
La diferencia entre un apaño y una práctica pro no está en las herramientas, sino en los reflejos : escribir código limpio, no confiar nunca en las entradas, estructurar, probar y entregar.
✓ Qué hacer
- Escribir PHP moderno : === por defecto, tipado (declare(strict_types=1)), funciones con responsabilidad clara.
- No confiar nunca en las entradas : validar en el servidor, consultas preparadas, escapar al mostrar.
- Estructurar (MVC, separación lógica/visualización) y aprovechar Composer (autoloading, bibliotecas probadas).
- Cifrar las contraseñas (password_hash), proteger los secretos (variables de entorno), HTTPS, autorización.
- Escribir pruebas (PHPUnit) sobre la lógica crítica ; medir antes de optimizar.
- Apoyarse en los frameworks (protecciones por defecto) y entregar hasta el final (despliegue, CI/CD).
✗ Qué evitar
- Concatenar datos en el SQL (inyección) o mostrar datos en bruto (XSS).
- Guardar una contraseña en claro o un secreto en el repositorio Git.
- Confiar en la validación de cliente (burlable) ; mezclar lógica y visualización (spaghetti).
- Descuidar las pruebas (« funciona ») y dejar regresiones silenciosas.
- Optimizar prematuramente en lugar de medir y focalizar ; sobreingeniería.
- Mostrar los errores detallados en producción (divulgación de información).
Guion listo para decir — revisar su práctica antes de entregar (30 s)
« ¿strict_types y === ? ¿Entradas validadas en servidor, SQL preparado, visualización escapada, CSRF ? ¿password_hash, secretos en .env, HTTPS, autorización ? ¿PHPUnit en verde, errores registrados ? Si un no, corrijo antes de entregar. »
Modelo copiar-pegar — registro seguro (cifrado + preparada)
prepare("INSERT INTO users (email, hash) VALUES (:email, :hash)");
$stmt->execute(["email" => $email, "hash" => $hash]);
function verifier(string $saisi, string $hash): bool {
return password_verify($saisi, $hash);
}TPE / presupuesto pequeño
Un solo hábito por trimestre basta : consultas preparadas primero, el resto después.
Pyme Constantine
Adaptar los rituales a los picos y desplazamientos : un hueco de revisión de código y pruebas cada semana.
Remoto / híbrido
La disciplina n.º 1 a distancia : revisiones escritas y pruebas en verde, incluso para pequeños fixes.
Intercultural
Verificar los usos locales en lugar de suponer : una regla de autorización inusual debe alertar en todas partes.
Desafío 48h — aplica mañana
Pasa tu página principal por la criba : cero concatenación SQL, cero visualización en bruto, cero secreto versionado. Corrige la primera desviación encontrada.
- Conozco los reflejos a seguir y las trampas a evitar.
- Verifiqué mis 3 puntos críticos (SQL, visualización, secretos).
- Hice el desafío 48h o planifiqué su fecha.
Antes de entregar, Riad revisa su práctica. ¿Qué reflejo lo protege mejor ?
Regla de oro : un buen desarrollador PHP no es quien programa más rápido, sino quien entrega aplicaciones limpias, seguras, fáciles de mantener y realmente puestas en producción.