Así es como se ve el PHP moderno

El título es realmente pretencioso, ¿no? Sí lo es. Aunque he estado trabajando con PHP durante años, ¿cómo podría indicar cuáles son las mejores prácticas y herramientas para el trabajo? No podría, pero lo haré.

Estoy viendo un cambio real en la forma en que los desarrolladores están haciendo su trabajo con PHP, no solo el lenguaje está cambiando drásticamente para volverse más maduro y robusto con nuevas versiones y mejoras, sino que todo el ecosistema que lo rodea está cambiando.

Se están creando nuevas herramientas, bibliotecas, marcos y artículos, se están definiendo patrones para hacer que el código sea más elegante y fácil de entender. Varias personas están pensando en formas de hacer que el trabajo (y su vida como desarrollador) sea más productivo, limpio y divertido.

No soy uno de los primeros en adoptar nuevas tendencias, de hecho, solo adopto una nueva herramienta cuando estoy seguro de que hay una comunidad detrás de ella y realmente creo que mejorará mi trabajo. Lo que siempre hago es intentar escribir mi código siguiendo las mejores prácticas.

Por eso, me tomó tiempo comenzar a usar cosas como Composer y PHPUnit. Hace aproximadamente un año, más o menos, abrí mi corazón a todas esas cosas nuevas y brillantes.

Primero vino PSR, luego Composer, PHPUnit, Travis-ci y varias otras bibliotecas y herramientas asombrosas. ¡Incluso estoy usando un IDE ahora (Vim FTW, pero PHPStorm con la integración XDebug es imprescindible para un flujo de trabajo sano)!

¿Qué es moderno?

Hay toneladas de artículos en la web sobre lo horrible que es PHP, cómo su vida sería terrible si tuviera que trabajar con código PHP, lo feo que es el lenguaje y cualquier otra cosa que se le ocurra.

Si va a trabajar con código heredado, tal vez su vida no sea tan buena, pero si tiene la oportunidad de trabajar en un nuevo proyecto y puede usar todas las herramientas nuevas, verá este nuevo PHP. Voy a hablar.

Tengo varios problemas para trabajar con PHP a diario, pero uno no puede cerrar los ojos a los cambios que se están produciendo en el lenguaje, la comunidad y el ecosistema. Hay un largo camino por recorrer, pero las cosas están madurando en la tierra de PHP.

Comencé a crear un SDK para una API interna en la empresa para la que trabajo, solo como un proyecto favorito, y decidí seguir las mejores prácticas. La mayoría de ellos ya los estaba haciendo, pero hice algunos cambios en la forma en que hago algunas cosas. Esos cambios y lo que aprendí en el último año son el tema de este artículo y lo que llamo PHP moderno.

Empecemos por el flujo de trabajo

Como dije, soy un recién llegado a esta cosa IDE, pero fue amor a primera vista. PHPStorm es una gran pieza de software. Es mi primer y único IDE. Fue mi primer intento y ni siquiera necesitaba probar otro.

La integración con XDebug es perfecta, resolución del espacio de nombres PHP, integración del compositor, integración git, autocompletar, generación de código, refactorización de código. Podría seguir y seguir.

No creo que debas usar un IDE, de hecho, este punto es completamente personal. Debe usar lo que se adapte a sus necesidades: Vim, Atom, Emacs, Bracket, NetBeans, PHPStorm, Eclipse, lo que sea. Dos puntos importantes aquí son la productividad y la ergonomía. Su IDE / editor de texto debe estar ahí para ayudarlo.

Sin embargo, para mí, un gran punto es la integración del depurador. Para escribir código para proyectos grandes (en realidad también para los pequeños), debe usar un depurador decente. Olvidemos esos var_dumps y print_rs. Necesita empujar esas variables en tiempo de ejecución, analizar rastros de pila, establecer puntos de interrupción. Estas cosas son esenciales y facilitan el desarrollo y la refactorización.

Ni siquiera sé si hay otras opciones aquí, XDebug tiene todo lo que necesitas. ¿Tienes unos minutos? Si aún no lo ha hecho, tómese un momento para configurar XDebug e integrarlo en su IDE o editor de texto. Empiece a depurar su código con las herramientas adecuadas.

La otra herramienta a la que quiero llamar su atención es GitHub. Se podría escribir otro artículo completo sobre lo buenos que son Git y GitHub y por qué debe comenzar a mantener su código bajo un sistema de control de versiones. Pero quiero mostrarte otra razón.

El enfoque aquí es la integración.

Hay varias herramientas que se integran con GitHub y debería comenzar a usarlas. Esas herramientas pueden generar métricas, ejecutar pruebas, ejecutar trabajos por usted durante un proceso de integración continuo y hacer todo tipo de cosas en su flujo de trabajo. La integración es una buena razón para que comiences a usar GitHub, todos los demás están sujetos para otro momento.

Gestión de la dependencia

Otro punto en este ecosistema PHP moderno es la gestión de dependencias, y Composer es la herramienta para el trabajo.

Composer tiene 5 años, pero me parece que la adopción masiva tuvo lugar hace un par de años. Tal vez porque no soy uno de los primeros en adoptar o tal vez porque los desarrolladores de PHP son reacios a cambiar.

Esta herramienta proporciona una interfaz para Packagist, que es un repositorio de paquetes PHP que consta de bibliotecas, proyectos y herramientas PHP, cuyo código fuente se almacena en Github (u otros lugares como BitBucket).

Todas las bibliotecas de las que hablo en este artículo, y tal vez uno de esos proyectos favoritos tuyos, se pueden agregar a tu proyecto con un simple

$ composer require package_vendor/package_name

Si no conoce el proveedor de un paquete, puede searchbuscar un paquete e instalar el correcto.

$ composer search package_name

Composer sería una gran herramienta si solo hiciera este trabajo, administrara dependencias, pero hace mucho más. Tómese un tiempo para instalar Composer y lea la documentación.

Interfaz de línea de comandos bien hecha

Realmente me gusta probar ideas rápidamente usando interfaces CLI. Para mí, una de las mejores herramientas REPL es IPython. Le ayuda a autocompletar su código, le permite definir funciones fácilmente, facilitar el acceso a la documentación y varias otras características sorprendentes. La desventaja para nosotros es que la herramienta es para Python, no PHP.

En el mundo de PHP tenemos algo llamado "modo interactivo" al que se puede acceder por terminal, simplemente escribiendo

$ php -aInteractive mode enabled
php >

En este punto, está en el modo interactivo y puede comenzar a probar algo. Funciona, pero la herramienta es demasiado intuitiva. Lo he probado varias veces pero, como sabía lo que IPython podía hacer, no pude seguir usándolo.

Para nuestra suerte, hay una nueva CLI (interfaz de línea de comandos) en el bloque y su nombre es Psysh. Psysh es una herramienta increíble, llena de características interesantes y se puede instalar globalmente o por proyecto usando Composer.

The nicest Psysh feature for me is inline documentation. Accessing the doc for a PHP function without heading over to Php.net is great. The downside is that you need to do few things before it is fully functional.

After installing it, type the following commands (I’m using Debian here, this may not work for everyone) in order to get it working properly

$ apt-get install php7.1-sqlite3$ mkdir /usr/local/share/psysh$ wget //psysh.org/manual/en/php_manual.sqlite -o /usr/local/share/psysh/php_manual.sqlite

The first command is not mandatory and if you have the Sqlite already installed you can skip this step. The second command creates the directory to store the documentation and the third line downloads and save the doc into the previously created directory. Remember, all these commands must run as root.

Now you have this

Head to Psysh and learn more about this awesome tool.

You should start testing

Este es un mantra que me digo a mí mismo todos los días. Como mucha gente, no pruebo mi código tanto como sugiere TDD. Estoy haciendo pruebas ahora y lo he estado haciendo durante el último medio año, y hay un largo camino por recorrer.

Decidí aprender sobre las pruebas cuando trabajaba con un proyecto heredado complejo. El código era tan frágil y rígido que cada vez que añadíamos código, se rompía algo. ¿Nueva caracteristica? ¡Implementa y rompe algo! ¿Arreglando un error? Crea otro.

Ese fue un gran problema, del que hablé en otro artículo, y me hizo comenzar a darle una oportunidad a las pruebas.

La primera herramienta que me presentaron fue PHPUnit. Como se indica en el sitio oficial

PHPUnit es un marco de pruebas orientado a programadores para PHP.

Es una instancia de la arquitectura xUnit para marcos de pruebas unitarias.

So, PHPUnit is a framework for helping you create tests for your projects, unitary tests. It gives you several functions to test the outcome of your code and generate a nice output with the result from those tests.

Since I started thinking about tests, reading and talking to people about it, I’ve discovered another great tool, which complements the work you’ve put in those unitary tests, it is calle Behat, which is a BDD framework for PHP.

BDD (Behavior-Driven Development) is a development process which came from TDD (Test-Driven Development). Those acronyms are not important now, what is important is that you can specify your tests using a more natural language, a language that non-technical folks can understand.

This language is called Gherkin and is used to describe the expected behavior being tested. A test description, using Gherkin, looks like this

Behind those lines there is PHP code that is called whenever there is a match between a line and a regex pattern specified in the PhpDoc of the method. This code implements those steps and what a real user would do, using your SDK, application or web system.

The workflow with Behat is so smooth. After everything properly configured, you start writing all possible scenarios for testing a feature. The first time you run Behat, it gives you all the method templates you should add to your PHP Context class in order to implement each step in a scenario.

After that, you start writing the actual code for each step and keep repeating this cycle.

  • Implement PHP code for a step
  • Run tests
  • If everything is fine, write PHP code for another step
  • If something is broken, fix it

After half an hour of configuring and reading documentation, you are prepared to use Behat, you’ll see that in the end it is all PHP code and you already know how to program with it.

Continuous Integration

Continuous integration (CI) is a process - a way to do something, and this thing, for us software engineers, is creating software.

In plain English, it is the act of incorporating small chunks of code constantly (maybe several times a day) into your code base. Code which has been tested and did not break anything. CI helps you automate the building, testing and deployment of your applications.

With a few clicks you can integrate your GitHub project with Travis CI and every push to your repository will run those tests you created with PHPUnit and Behat, telling you whether the the last feature you’ve implemented is ready, or not, to be merged. Besides that, you can use Travis CI to deploy your code to production and staging.

Having a nice pipeline of work with a well defined process is great and Travis CI can help you with this job. Follow this nice Getting started and discover how interesting it is to think about the process of software development, not just the code itself.

Adhere to PSR-1 and PSR-2

If you don’t know what PSR is, you should. Actually, PSR stands for PHP Standard Recommendations and is proposed by PHP-FIG (PHP Framework Interop Group), a consortium formed by members from the biggest PHP projects, frameworks and CMSs, which are thinking about the future of the language, ecosystem and discussing standards to be followed.

For a long time, PHP had no coding style. I’m not that old, but every time I looked into someone’s project or library, it was following a different style. Sometimes the bracket was left in one position, sometimes it was put in the next line, different approaches were used to deal with long lines and every other combination of style and preference you could think of. It was a mess.

PHP-FIG does many other jobs, but by proposing a single unity of code, they are saying “Let’s stop worrying about code style, let’s everyone follow a standard and start thinking about creating great software”. Now, whenever you take a look at someone’s code you just worry about understanding how it works, not blaming the format, the structure.

There are, until the end of this article, 9 accepted PSRs proposing common solutions for common problems. But if you don’t know anything about those standards, start with the PSR-1 and PSR-2.

These standards propose the modern PHP coding style. Make sure you read them before start using them. Don’t think you’ll remember all of them when coding, it is a process, but to make you sure, there are tools to help you with it.

PHP CodeSniffer is a tool you can find on Packagist that you can install with Composer. I don’t think the repository name was the best choice, because it ships two different tools, phpcs and phpcbf.

Phpcs is the code sniffer, it will scan your entire code, looking for parts that are not following the configured coding standard.

You can use several coding standards with phpcs and you can even create your own. At the end of the code scan, phpcs shows you a list of the pieces of code not following the standard. It is great.

Now, how to change everything which is wrong? You could open every file, change the code, run phpcs again, see the error not being shown, and repeat the process. It’ll be extra boring.

To solve this problem, PHP CodeSniffer came with another tool, called phpcbf, or PHP Code Beautifier. You run phpcbf, following the same rule set and, voilá, it fixes everything for you, or it tries to do its best without breaking your code.

Try to create the habit of running phpcs and phpcbf before pushing any changes in your code to the repository, this will ensure that all of your code adhere to the standards and if someone likes your tool/project and wants to contribute, they will have no problem reading it.

Frameworks

I’m not going to dedicate too much time discussing frameworks. There are several good ones out there, each one with its ups and downs. Personally, I prefer not to use those big frameworks, with everything inside. I like the idea that you must use just what you need.

If you need a HTTP client, use Guzzle. If you need a template engine, use Twig. If you need a router, find a good component which suits your needs and use it. Glue these components together and create your application.

Symfony is doing a great job towards this concept. You can use the entire framework for a project, or you can just take whatever you want and use it. Simple as that.

However, whenever I need a framework to write an application, I chose one of the so called microframeworks. They are really small, offer just the basics and are easy to customize and easier to make them follow your project structure.

My microframework of choice is Slimframework and I think you should read about it. It is simple for doing small projects, but it gets a bit more complex for bigger ones.

By the way, and this is for those who are starting with programming, I really think that before adopting a framework and dying for it, you should try to create your own. This will give you the understanding of the whole mechanism and ease the adoption of a big one.

The Modern PHP Toolset

Let’s finish this article with a list of links. To me, these components, tools and libraries represent a great deal of what Modern PHP is:

  • Slimframework: a nice and cool microframework
  • Symfony: a bigger framework which is filled with great and reusable components
  • Guzzle: a simple and easy to use HTTP client
  • PHPUnit: a framework for unitary testing
  • Behat: a framework for Behavior-Driven Development
  • PHPCS/CBF: code sniffer and code beautifier
  • Faker: fake data generator
  • Psysh: a runtime developer console (CLI) full of amazing features
  • Composer: dependency management and other useful features
  • Packagist: package repository
  • Twig: template engine

The title was really pretentious, I know. What I really wanted to show here is that PHP is evolving and the ecosystem is evolving at the same (maybe faster) pace.