Ya he compartido algunas de las próximas características de PHP 7, en este artículo pensé en echar un vistazo a algunos de los malos patrones que deberíamos dejar de usar cuando cambiemos al rapidísimo PHP 7. Y no olvide revisar nuestro nuevo mega-benchmark de la versión final de PHP 7.2.
Las Mejores Prácticas de PHP 7 o Lo Que No Debes Hacer en PHP 7
- No utilice las funciones mysql_
- No escriba el código de desperdicio
- No use etiquetas de cierre PHP
- No pase por referencia si no es necesario
- No realizar consultas en un bucle
- No usar * en las consultas SQL
- No confíe en las entradas del usuario
- No intente ser inteligente
- No reinvente la rueda
- No descuidar otros idiomas
1. No utilice las funciones mysql_
Finalmente ha llegado el momento en que no sólo se le aconsejará dejar de usar las funciones de mysql_. PHP 7 las eliminará por completo del núcleo, lo que significa que necesitará moverse a las mucho mejores funciones de mysqli_, o a la implementación de PDO aún más flexible.
2. No Escriba el Código de Desperdicio
Este puede ser un asunto sencillo, pero será cada vez más importante porque los aumentos de velocidad en PHP 7 pueden ocultar algunos de sus problemas. No se conforme con la velocidad de su sitio simplemente porque el cambio a PHP 7 lo hizo más rápido.
Para entender lo importante que es la velocidad y lo que puede hacer para mejorar las cosas, eche un vistazo a nuestro artículo de la guía para principiantes sobre la optimización de la velocidad.
Como desarrollador, siempre debe asegurarse de cargar los scripts sólo cuando sean necesarios, concentrarlos cuando sea posible, escribir consultas eficientes a la base de datos, usar el caching cuando sea posible y así sucesivamente.
Para un rápido y sencillo impulso a tu optimización general, plantéate minificar tu código. Kinsta ha incorporado una función de minificación de código en el panel de control de MyKinsta, permitiendo a los clientes activar la minificación automática de CSS y JavaScript con un solo clic.
3. No Use Etiquetas de Cierre PHP al Final de un Archivo
Si echa un vistazo, la mayoría de los archivos centrales de WordPress omiten la etiqueta PHP de terminación cuando un archivo termina con código PHP. De hecho, el Marco de Zend lo prohíbe específicamente. No es requerido por PHP y al omitirlo al final de un archivo se asegura de que no se pueda agregar ningún espacio en blanco.
4. No Pase por Referencia si No es Necesario
Personalmente no me gusta pasar por referencia. Entiendo que en algunos casos es útil, pero en muchos otros hace que el código sea más difícil de entender y seguir y especialmente difícil de predecir el resultado.
Aparentemente, la gente piensa que hace su código más rápido, lo cual, según los programadores respetables de PHP, no es cierto.
Un ejemplo de por qué las referencias son malas es el PHP construido en shuffle() o sort(). En lugar de devolver una matriz barajada u ordenada, modifican el original, lo cual es completamente ilógico en mi opinión.
5. No Realizar Consultas en un Bucle
Realizar consultas a la base de datos en un bucle es simplemente un desperdicio. Esto pone una tensión innecesaria en sus sistemas y es probable que pueda lograr el mismo resultado más rápido fuera del bucle. Cuando me encuentro con una situación en la que esto sería necesario, normalmente puedo resolver el problema con dos consultas separadas que utilizo para construir una matriz de datos. Luego hago un bucle sobre la matriz, sin necesidad de realizar consultas en el proceso.
Debido a la forma en que funciona WordPress puede haber algunas excepciones a esto. Mientras que get_post_meta() tomará un metavalor de la base de datos, puedes usarlo en un bucle si estás haciendo un bucle a través de los metadatos de una entrada específica. Esto se debe a que cuando lo usas por primera vez, WordPress recupera todos los metadatos y los almacena en caché. Las llamadas posteriores utilizan los datos en caché, no las llamadas a la base de datos.
La mejor manera de resolver estas cosas es leer la documentación de las funciones y utilizar algo como el Query Monitor.
6. No Usar * en las Consultas SQL
De acuerdo, este es más bien un problema de MySQL, pero tendemos a escribir nuestro código SQL en PHP, así que digo que es un juego justo. En cualquier caso, no utilice caracteres comodín en las consultas SQL si puede evitarlos, especialmente si tiene una base de datos con muchas columnas.
Especifique las columnas exactas que necesita y sólo recupere aquellas. Esto ayuda a minimizar el uso de sus recursos, proteger sus datos y hacer las cosas lo más claras posible.
Mientras esté en el tema de SQL, conozca sus funciones disponibles y pruebe la velocidad tanto como sea posible. Cuando se calculan promedios, sumas o números similares se utilizan funciones SQL en lugar de las funciones PHP. Si no está seguro de la velocidad de una consulta, pruébela y pruebe otras variaciones – utilice la mejor.
7. No Confíe en las Entradas del Usuario
No es prudente confiar en la entrada del usuario. Siempre filtre, desinfecte, escape, revise y utilice las medidas de seguridad. Hay tres problemas con los datos de los usuarios: los desarrolladores no tenemos en cuenta todas las posibilidades, a menudo son incorrectos y pueden ser intencionadamente maliciosos.
Un sistema bien pensado puede proteger contra todo esto. Asegúrese de utilizar funciones incorporadas como filter_var() para comprobar que los valores son correctos y las funciones de escape y otras funciones cuando se trabaja con bases de datos.
WordPress tiene un montón de funciones para ayudarte. Eche un vistazo al artículo Validación, escape y sanitización de datos del usuario para obtener más información.
8. No Intente ser Inteligente
Su meta debe ser escribir un código elegante que exprese sus intenciones de la manera más clara. Es posible que pueda reducir 0,01 segundos adicionales en cada carga de la página acortando todo a variables de una letra, usando lógica ternaria multinivel y otras astucias, pero esto realmente no es nada comparado con los dolores de cabeza que se causará a sí mismo y a todos los demás a su alrededor.
Nombre sus variables apropiadamente, documente su código, elija la claridad en lugar de la brevedad. Mejor aún, utilice código orientado a objetos estandarizado que más o menos se documente a sí mismo sin necesidad de muchos comentarios en línea.
9. No Reinvente la Rueda
PHP existe desde hace mucho tiempo, los sitios web se han creado desde hace aún más tiempo. Lo más probable es que lo que necesite hacer, alguien lo haya hecho antes. No tenga miedo de apoyarse en los demás, Github, Composeris, Packagist es su amigo.
Desde los loggers hasta las herramientas de manipulación del color, desde los profilers hasta los marcos de pruebas unitarias, desde las APIs de Mailchimp hasta Twitter Bootstrap, todo está disponible con sólo pulsar un botón (o escribir un comando), ¡úselos!
10. No Descuidar Otros Idiomas
Si usted es una persona de PHP es ahora una práctica estándar saber sobre HTML, CSS, Javascript y MySQL por lo menos. Cuando tenga un buen manejo de estos lenguajes, es hora de aprender Javascript de nuevo. Javascript no es jQuery. Usted debe aprender Javascript correctamente para poder utilizarlo eficientemente.
También te recomendaría aprender todo sobre PHP orientado a objetos, es un salvavidas y hará que tu código mejore en órdenes de magnitud. También te abrirá las puertas a lenguajes como C# y Java, que serán mucho más fáciles de entender con la POO en tu haber.
Amplíe su conocimiento aprendiendo sobre los gestores de paquetes, scripts de construcción, Coffeescript, LESS, SASS, YAML, motores de plantillas y otras herramientas impresionantes. Recomendaría encarecidamente que se miraran otros marcos, en particular el de Laravel.
Cuando le va bastante bien con estos, ¿qué hay de Ruby, Ruby on Rails, desarrollo de aplicaciones para Android, iPhone, Windows Phone? Uno pensaría que no tiene sentido porque estos caen fuera de su zona de confort y necesidades de trabajo, pero ese es el punto. Cada idioma tiene algo útil que enseñar y un poco de conocimiento extra nunca hace daño. No es un accidente que todos los principales desarrolladores de PHP sepan mucho sobre otros lenguajes de programación!
Hi, my name is Daniel, I'm the CTO here at Kinsta. You may know me from Smashing Magazine, WPMU Dev, Tuts+ and other WordPress/Development magazines. Aside from WordPress and PHP I spend most of my time around Node, React, GraphQL and other technologies in the Javascript space.
When not working on making the best hosting solution in the Universe I collect board games, play table football in the office, travel or play guitar and sing in a pretty bad band.
Deja una respuesta