“¡Pero es que PHP es un lenguaje muy desordenado, hay mucho código espagueti!”. ¿Alguna vez escuchaste a alguien decir esta frase? ¿Y si te digo que con PHP puedes tener código impecable, pero más allá de eso, código reemplazable? 👀.
.
Muchos programadores que tocaron PHP acabaron dejándolo porque “es un lenguaje muy desordenado”. Pero la realidad es que PHP es un lenguaje que, sabiéndolo dominar, brinda muchas ventajas y un orden y modularización excelente, de hecho gracias a este orden podemos hacer cosas increíbles con el código que no sabías que podemos hacer 😄.
PHP es un lenguaje tan flexible que, desafortunadamente, puede prestarse a escribir smell code, por ejemplo el siguiente:
<?phpif($a <=> $b){
echo'<div class="card">
<span class="hour">00:00</span>
';
if ($Cheese == "tool") echo"<UL>
<LI>uno</LI>
<LI>dos</LI>
</UL>";
echo'
</div>';
}else{echo"<p>No hay resultados</p>";}
?>Este código funciona, pero como puedes ver, es ilegible. ¿Tú entiendes qué hace eso? ¡Lo sé, yo tampoco! Esta es la razón por la cual a muchos programadores no les gusta trabajar con PHP, pero ¿realmente de quién es el problema? 🤔.
.
Somos responsables del código que escribimos, y si bien no siempre podemos mantener un código 100% limpio, existen muchas técnicas que nos ayudan a minimizar el smell code en cualquier lenguaje, incluyendo PHP, desde la modularización de código hasta el uso de principios SOLID o patrones de diseño. Puedes profundizar más en estas técnicas en el Curso de Buenas Prácticas para Escritura de Código 👀.
.
Independientemente de las buenas prácticas para la escritura de código, quiero hablarte de algo maravilloso que existe en PHP y que nos permite tener un código reemplazable y reutilizable dentro de cualquier sistema PHP: Los estándares PSR 📜.
Imagina poder utilizar un sistema de rutas que te descargaste de alguna dependencia que encontraste por ahí, y después de algunos meses cambiarlo por otro sistema de rutas sin tener que tocar nada del código que ya tenías escrito para el primero… ¡En PHP es posible! Y esto es gracias a los estándares PSR 🎉.
Las siglas PSR se refieren a PHP Standards Recommendations (recomendaciones estándar de PHP para los amigos 😉). Como el mismo nombre menciona, son un conjunto de estándares y recomendaciones que crearon un grupo de programadores muy reconocidos del lenguaje (y que han aportado con excelentes librerías). Básicamente ellos armaron su squad llamado “php-fig” y dijeron: “¡Oigan!, vamos a proponer estos estándares para este lenguaje, así podremos reutilizar el código entre librerías de una forma más fácil y que haya menos código espagueti 😄”.
.
Estos estándares definieron desde cómo nombrar nuestras variables hasta cómo hacer el autoimport de nuestros archivos. Actualmente existen 20 PSR’s propuestos, pero no todos están en uso debido a que algunos fueron actualizados y otros simplemente fueron olvidados, así que podemos dividirlos en 4 grupos:
Son muchos estándares, sin embargo veamos cuáles son los más populares 👀, siempre puedes ver el resto de estándares en la página web de PHP-FIG 😄:
.
PHP Standards Recommendations
Espera, ¿qué?, ¿del 0 te saltaste al 4? ¡Sí!, pero esto tiene su explicación: PSR-0 fue el primer estándar de autocarga de archivos que se definió para PHP, sin embargo, fue deprecado y reemplazado por PSR-4.
.PSR-4 es probablemente el estándar más popular, seguramente has escuchado de él si has trabajado con Laravel 😄. Recordemos que el manejador de dependencias de PHP es Composer, por lo que este ya viene preparado para trabajar con PSR-4.
.
En pocas palabras, PSR-4 te dice que, para que podamos construir un sistema de autocarga de archivos, el namespace de los archivos a cargar debe ser exactamente igual a la ruta donde se encuentra alojada dicha clase, por ejemplo, supongamos que tengo la clase User guardada en el directorio app/Classes/People/User.php, el archivo debería verse así:
User.php
namespaceapp\Classes\People;
classUser{
# code...
}
Por su puesto que tu puedes generar un sistema de autocarga que no obedezca estas reglas, que sea capaz de detectar archivos en otras carpetas con otros namespaces y que funcione, pero recuerda, estas son las recomendaciones que nos da PSR. Composer ya conoce esto, por lo que si no sigues el estándar, Composer nunca encontrará tu archivo, y sí, las mayúsculas y minúsculas cuentan 👀☝.
Esta recomendación hace alusión a cómo se deben estructurar los requests y los responses dentro de PHP, y aquí es donde se pone bueno el asunto, ya que esto hace que todo parezca magia 👀.
Recordemos que una solicitud HTTP está manejada por una petición y una respuesta, eso es lo que llamamos requests y responses. PSR-7 trabaja con interfaces, que básicamente son unos contratos que te dicen qué métodos debe implementar obligatoriamente una clase 📝.
.
Esto hace que, dos o más programadores puedan crear librerías completamente diferentes que estructuren peticiones HTTP usando dichas interfaces, y que cualquier otro programador pueda implementar una de esas librerías en su proyecto, y si por alguna razón no le gusta una, ¡puede cambiar a otra sin ningún problema y sin modificar el código! Por ejemplo, laminas-diactoros es una de estas librerías que manejan solicitudes HTTP implementando PSR-7 👀.
.
¿Y no hay problema si cambio una por otra? ¿No tengo que modificar nada? ¡No! Esa es la ventaja de usar las convenciones PSR, todo funciona y puedes quitar y poner cuando desees 😎.
Mientras que PSR-7 nos exponía interfaces para estructurar requests y responses, PSR-15 nos expone interfaces para definir cómo vamos a manejar esos requests y responses, e incluso poder añadir una capa de middlewares.
.
Sé que es difícil notar la diferencia, pero no te preocupes, te explico ☝: PSR-7 define la estructura de cómo debe formatearse un request y cómo debe mandarse un response, es decir, podemos tener un objeto Request que contenga ciertos datos de la petición dentro, o podemos tener un objeto Response que nos permita mandar diferentes tipos de respuestas (HTML Response, JSON Response, etc.).
.PSR-15 nos dice cómo vamos a manejar esos requests y responses, es decir, qué controlador llamar, si necesito llamar un middleware antes, mandar la respuesta al cliente, etc. Es básicamente manipular esas estructuras que ya nos dió PSR-7 😄.
.
Un middleware es código intermedio que se ejecuta antes de llegar a ejecutar el código de nuestro controlador (nuestra lógica principal), por ejemplo, podemos tener un middleware que verifique si un usuario está autenticado antes de que nuestro controlador haga su trabajo.
.
Podemos mirar el esquema de un middleware de esta forma:
Básicamente, el request pasa por el middleware, este hace sus validaciones, y si todo va bien llega hasta el núcleo de la aplicación (el controlador) para luego emitir el response 👀.
Estás en todo tu derecho de no usar PSR, pero es como quedarte fuera de los chicos cool que sí lo usan 👀. Recuerda que estas convenciones están ahí para hacer más fácil nuestro desarrollo con PHP y para evitar caer en malas prácticas 😄.
.
Recordemos que, a fin de cuentas, PSR son solo sugerencias, no pasa nada si no las usas, pero cualquier librería que hagas será incompatible con otras dependencias que sí usan PSR (lo que provocaría que nadie use tu librería), y si quisieras usar una librería de PHP que te gustó, pero que usa PSR, no podrías porque no estarías trabajando bajo el estándar.
.
Probablemente te estarás preguntando: “muy bonito y todo, pero ¿cómo se implementa PSR?”, recuerda que PSR es una convención, no es algo que debas descargar (a no ser que implementes una recomendación que te pida usar interfaces 👀), pero por lo general, basta con que trabajes bajo las reglas que proponen por cada estándar (que las puedes encontrar en la página de PHP-FIG por su puesto).
.
Por ejemplo, si usas Composer, ya estás trabajando sobre el estándar de tener los namespaces que coinciden con la ruta del archivo (PSR-4), o si estás usando laminas-diactoros entonces ya usas psr-7 😄.
.
.
¡Genial! Ahora que ya sabes cómo trabajar como un master con PHP seguramente irás a hacer un proyecto increíble 😉.
.
Toma el Curso de Introducción a PHP 2018 y el Curso Avanzado de PHP en donde trabajarás un proyecto con PHP desde cero y empezarás a implementar algunas convenciones PSR, de esa forma empezarás a darte cuenta de cómo estas convenciones hacen que trabajar con PHP sea increíblemente fácil y fortalecerás tus habilidades como programador de PHP 😉.
.
Estaré pendiente de los comentarios por si tienes alguna duda, recuerda que puedes aprender más cosas como estas suscribiéndote a mi canal donde estaré subiendo cosas interesantes. 💚
PHP Standards Recommendations
PSRs: estándares en PHP
Estándares PSR para escribir código en PHP
PSR-4 Implementation: Composer
PSR-7 Implementation: laminas/laminas-diactoros
PSR-15 Implementation: woohoolabs/harmony
Esto es super genial, que potencial tan grande es un mundo de posibilidades pero esta en nosotros seguir las mejores reglas y estándares, y las PSR de PHP sin duda hacen parte de esto, quiero decirte que esta super genial tu análisis hay mucho trabajo para aclarar las cosas de forma sencilla (esta es la mejor forma de aprender mejor) saludos