Xdebug + PHPStorm + Windows

Engana-se quem pensa que o Xdebug serve apenas para extrair relatório de cobertura de testes, o simples fato de eliminar a necessidade de var_dump|print_r seguido de die(); já me faz ganhar muito tempo de desenvolvimento e identificação de erros.

Mas por que Windows?

Dois motivos: 1 - já fiz post falando de Linux e Mac (são praticamente a mesma coisa pra configurar) e, 2 - porque no ano passado migrei para o Windows 10. Meu Macbook Air tava apanhando para aguentar meu ritmo de trabalho, fiz uma péssima compra de um iMac (a qual só me trouxe dor de cabeça) e então decidi me desapegar um pouco da Apple. Em linhas gerais, o Windows vem me atendendo muito bem para o desenvolvimento com a stack que utilizo: PHP (ZF/Laminas, Symfony) + mysql + html/css/js, e no fim do dia ainda tenho uma ótima válvula de escape: jogos, jogos e mais jogos. O Windows é um Sistema Operacional, e como tal, o PHP, mysql e tudo mais que você usa para desenvolver, tende a rodar sem problemas, assim como ocorre no Linux e Mac. Tendo isso em mente, nada impede de usarmos boas práticas de desenvolvimento como testes, código limpo, uma boa IDE e o Xdebug, que é o assunto deste post. Atualmente contamos com diversas IDEs para desenvolvimento em PHP, cada qual com suas qualidades, mas sem receber nada por isso, muito pelo contrário, pagando todos os meses pela licença, sugiro o PHPStorm.

Por que PHPStorm?

Há muitos anos que utilizo o PHPStorm, de fato passo longe de utilizar todos os recursos da IDE, mas os essenciais para a minha produtividade, me deixam tão confortável que sequer penso em utilizar outra, mesmo que isso me custe quase 60 reais a cada mês. Com essa IDE, além de codar, faço operações simples de banco de dados, rodo coisas pelo terminal e uso o Git. Nas funcionalidades do git tenho os principais recursos à mão, mas de longe o melhor deles é a resolução de conflitos. Mas o foco deste post é debugar código em PHP utilizando esta IDE, então vamos lá.

Instalando

A instalação no Windows é bem simples. Eu que já fiz no Linux e no Mac, notei que no Windows é o mais simples de todos, enquanto que no Mac é o mais complicado, pelo menos na época que fiz, usando o Brew. Para começar, acesse este link e siga as instruções. É bem simples, você roda o php -i no terminal, pega o output, cola no campo de texto e o wizard te dá o passo a passo para baixar, instalar e configurar.

Depois de colar este conteúdo, clique em "Analyse my phpinfo() output".

O resultado será o passo a passo. Pode o seguir, fazendo isso, o xdebug estará instalado em sua máquina e pronto para ser utilizado com o PHP. Agora resta apenas configurar tudo para que o PHPStorm o reconheça.

Configurando o PHPStorm

A configuração para o PHPStorm é dividida em 3 etapas, a primeira é no php.ini enquanto que a segunda e terceira é na própria IDE.

php.ini

zend_extension = C:\php\ext\php_xdebug-[VERSION]-vc15-nts-x86_64.dll
xdebug.mode=debug
xdebug.client_host = localhost
xdebug.client_port=9000
xdebug.remote_handler="dbgp"
xdebug.start_with_request=yes
xdebug.idekey=PHPSTORM
xdebug.max_nesting_level = 250

PHPStorm > PHP

Na IDE, entre em File > Settings > Languages & Frameworks > PHP. Caso não exista nenhum interpretador (<no interpreter>), crie-o. Clique no botão com 3 pontos e adicione o executável do PHP. Clique no botao + e selecione o executável, que normalmente é reconhecido automaticamente, se a instalação do PHP que você fez o registrou nas suas variáveis de ambiente. Note que aqui já mostra que o x-debug foi reconhecido. Só clicar em ok no final da modal CLI interpreters. Agora seguimos para a configuração de debug.

PHPStorm > Debug

Ainda com as configurações abertas, vá em Languages & Frameworks > PHP > Debug. Há 2 pontos de atenção aqui:

1. a porta a ser utilizada já vem por padrão a 9000 e 9003. A menos que tenha necessidade de porta distinta, pode deixar assim, pois configuramos a porta 9000 no php.ini;
2. desmarcar a opção de parada na primeira linha para scripts de fora do projeto. Se marcado, qualquer script PHP que rode de fora do projeto, terá um breakpoint na primeira linha, o que é ruim, pois em caso de você rodar um composer update em qualquer lugar, ele ficará travado esperando você interagir.

O restante pode deixar tudo como vem configurado pela IDE. Só dar um Apply, Ok e pronto, podemos debugar.

Debugando no PHStorm

Para que possamos debugar, o primeiro passo é ativar o listener, um ícone de telefone na barra de ferramentas do PHPStorm.

Uma vez ativo, o telefone fica com um sinal de ligado/ouvindo.

Agora adicionamos um breakpoint em um código qualquer.

E agora é só rodar o script, fique à vontade pra escolher rodar diretamente pelo cli ou pelo server embutido. Vou rodar pelo server embutido pra mostrar como é a confirmação de uma conexão remota. Tenho um index.php com somente o exemplo da imagem acima, rodei o comando php -S localhost:8080, abri o browser, digitei localhost:8080 e dei enter. No PHPStorm aparece uma tela de confirmação, clico em "Accept" e pronto, o breakpoint entra em ação, basta ir rodando os steps conforme a necessidade.   Assim, é fácil usar o x-debug seja para trackear bugs, entender o fluxo de uma nova aplicação que você esteja conhecendo ou mesmo para extrair métricas de cobertura de testes. Isso tudo rodando pelo terminal, pelo browser, dando um "play" ou debug no código pela IDE.

Conclusão

Como você viu, a instalação e configuração no Windows é tão simples quanto é em uma distro Linux ou no MacOS. Basta colar o resultado de seu phpinfo e a própria ferramenta te mostra exatamente como proceder com a instalação, aí só configurar na sua IDE e tirar proveito do que o Xdebug pode lhe oferecer. Muitos devs, mesmo em meu trabalho, ainda usam técnicas como var_dump, print_r e die, absolutamente nada contra. O problema é quando um desses var_dump é esquecido e commitado no código, causando problemas. Essa é a grande vantagem de debugar, um breakpoint não modifica código, logo, não há perigo. Sem contar que, em caso de uma ação delicada como enviar um pedido à um parceiro, email ao cliente, deletar algo no banco, por exemplo, você pode facilmente interromper a execução antes que a caquinha seja feita, clicando no botão "stop", evitando algumas dores de cabeça. Mas para mim, a maior vantagem mesmo é poder seguir analisando linha a linha em tempo real, sem necessidade de dezenas de var_dump e repetições do mesmo fluxo até chegar o ponto de interesse. Sempre que inicio um novo projeto, uso o debug para conhecer o fluxo, coloco um breakpoint no ponto de interesse e vou rodando linha a linha enquanto conheço/documento o fluxo.