Con la introducción gradual del tipado en PHP se ha abierto un abanico de posibilidades que está cobrando cada día más fuerza entre la comunidad de desarrolladores que utilizan el lenguaje para sus proyectos. Además de las mejoras en el tipado, el AST introducido con PHP 7 y avances como el RFC recientemente aprobado sobre atributos están creando el escenario perfecto para potenciar más todavía este tipo de herramientas y facilitar su desarrollo.
¿Cómo aseguramos la calidad de nuestro código?
Hasta ahora el procedimiento básico por lo general consistía en lanzar nuestra suite de tests pero con la introducción de herramientas de análisis estático en el ecosistema de PHP se pueden realizar acciones o comprobaciones en código que no están cubiertas por los test o cuyos test serían difícilmente mantenibles.
Las herramientas de análisis estático no necesitan ejecutar el código para realizar sus comprobaciones, generalmente analizan el AST inspeccionando el código para validar si se cumplen una serie de condiciones o incluso modifican el AST para generar nuevo código corrigiendo problemas encontrados. Son de gran utilidad en proyectos nuevos, pero cobran más importancia todavía en proyectos legacy donde no hay tipado a excepción de algunos docblocks o la cobertura de tests no es la adecuada.
Si ejecutamos phan sobre nuestro proyecto que instancia la clase Circle con parámetros incorrectos como vemos a continuación obtendríamos un mensaje de error alertándonos a pesar de que se trata de código PHP perfectamente válido y que no provocaría un error de primeras. Por ejemplo con el siguiente código de clase e instanciación cualquiera de estas herramientas nos avisaría de que no estamos pasando el tipo de datos correcto sin tener que ejecutar nada.
Como hemos mencionado phan lanzaría un error similar al siguiente:
Esto que parece un ejemplo trivial se complica a medida que los proyectos van siendo desarrollados durante años, empieza a haber zonas de código tipado y no tipado, cada vez hay más niveles de abstracción, etc. Es por eso que la posibilidad de inferir los comportamientos adecuados que nos aporta cualquiera de estas herramientas tiene un valor enorme. Además de problemas de tipado son capaces de detectar otros smells comunes como código inalcanzable, o condiciones que siempre son verdaderas/falsas.
¿Qué necesitamos para empezar?
Si nos preocupa la calidad de nuestro código lo primero que deberíamos intentar es que sea legible y homogéneo, para eso deberíamos utilizar un coding standard, podemos crear o usar el que queramos y desde acceseo solemos trabajar con PSR-12 que es la última revisión del impulsado por el FIG, nuestro proyecto también debería utilizar autoloading con PSR-4 y gestionar las dependencias a través de composer como ya explicamos. Con esto nos aseguramos una base sólida y adaptada al uso actual del lenguaje que nos permitirá utilizar todo el abanico de herramientas existente.
¿Cómo empezamos?
Para utilizar todas las herramientas seguiremos el mismo proceso, instalaremos el paquete como dependencia de desarrollo usando composer, generaremos la configuración adecuada siguiendo la documentación si es necesario y podremos lanzarla a través del fichero situado en vendor/bin que nos ofrece el paquete. Es posible también usar la imagen de docker jakzal/phpqa que incluye muchas herramientas destinadas a calidad, esto nos puede ser muy útil cuando hay conflictos entre las dependencias o la versión de PHP utilizada en nuestro proyecto y en la herramienta que queremos usar.
En resumen, el uso de cualquier de las herramientas que mencionamos será similar a lo siguiente:
¿Qué herramientas podemos utilizar?
PHPCS
En nuestro caso utilizamos PHP_CodeSniffer para comprobar que se está aplicando un coding standard. Además incluye 2 herramientas: phpcs para identificar problemas y phpcbf para corregirlos de manera automática.
Con la siguiente configuración tendríamos lo básico para ver si un proyecto Symfony se está escribiendo siguiendo PSR-12, además excluimos del análisis algunos ficheros de los que no somos responsables directamente ya sea porque se autogeneran o son parte del framework o alguna librería.
Como en el resto de herramientas que estamos tratando nuestro objetivo es que la salida de la ejecución no reporte ningún problema. En el caso de phpcs la salida nos indicará también si es posible corregir el problema de manera automatizada con phpcbf.
PHAN
Con phan podremos comprobar la existencia de problemas en nuestro código como código inaccesible, variables en desuso, llamadas a métodos inexistentes, concordancia de tipos y muchas más cosas. Un punto interesante de phan es que además ademas cuenta con plugins, en el caso de un proyecto Symfony podríamos utilizar por ejemplo SymfonyAnnotationPlugin que forma parte del paquete drenso/phan-extensions.
PHPSTAN
Una de las bazas de phpstan es que nos forzará progresivamente a añadir tipado a nuestro código de manera que poco a poco sea más estricto. Podemos ver las reglas incluidas en la última release a fecha de publicación del artículo en la carpeta correspondiente a la configuración de los distintos niveles de la herramienta y nos permitirá utilizar un nivel predefinido o un conjunto de reglas personalizado.
PSALM
La última de las herramientas que hemos seleccionado y que forman parte de nuestras preferidas en acceseo es psalm desarrollada en vimeo. Como el resto de herramientas, a excepción de phpcs, es capaz de detectar un gran número de problemas en nuestro código. Además incluye la herramienta psalter que nos permitirá corregir algunos problemas de manera automática.
RECTOR / ECS
Por último y aunque no se trate de herramientas de análisis estático que simplemente nos reportan el estado de nuestro código no queríamos acabar sin hacer una mención a 2 herramientas que nos encantan desarrolladas por Tomas Votruba:
- Easy Coding Standard nos permite comprobar y corregir de manera automática muchos smells con sus sets.
- Rector está completamente enfocada en aplicar ciertas normas en nuestro código, incluye sets de cambios que nos permitirán actualizar de una versión a otra de PHP automatizando los cambios necesarios en nuestro código para utilizar las nuevas características del lenguaje o actualizar entre versiones de de una librería o framework. Aunque no es mágico y no va a resolver todos nuestros problemas en la actualización de un proyecto legacy hacia versiones actuales nos puede facilitar mucho la vida, además es muy sencillo implementar rectors personalizados con los que automatizar modificaciones en nuestro código.
Conclusiones
Hay muchísimas herramientas para ayudarnos a escribir mejor código por lo que sin duda se trata de un trabajo de balance, no necesitamos configurar repentinamente en un proyecto legacy varias herramientas en los niveles más altos porque probablemente habrá tantos errores que nos será complicado gestionarlos pero sí deberíamos introducirlas gradualmente e ir incrementando el nivel de la configuración para que sean más estrictas según vayamos solucionando los problemas que nos vayan planteando. Incluso algunas de estas herramientas se solapan en cuanto a funcionalidad por lo que tiene más sentido la incorporación gradual.
Por supuesto deberíamos tener en cuenta que añadir herramientas a nuestros procesos consume tiempo y energía por lo que configurar un entorno de CI cobra más sentido y nos facilita mucho la gestión del proceso de QA que implantemos, la configuración del job que ejecuta varias de las herramientas mencionadas en Gitlab CI sería tan sencilla como se puede apreciar a continuación por lo que desde acceseo os animamos a todos a que implementéis este tipo de flujos en vuestros entornos de trabajo.
