Neste texto busco auxiliar lideranças na gestão de produtos de software em PHP, abordando o fenômeno que conhecemos como legado de software, insights sobre estratégias e como podemos implementar processos e ferramentas de qualidade com PHP. Se trata sobre minha experiência empírica e em bases de autores de gestão de projetos e processos ágeis.

O PHP é uma linguagem amplamente usada, muito pela sua simplicidade, com servidor HTTP e camada de view abstraídos, com pouco conhecimento se pode fazer coisas realmente interessantes, é um processo diferente de linguagens fortemente tipadas, com compilação, estrutura, orientação a objetos obrigatória, etc.

Funciona muito bem para hobby e desenvolvimento rápido de produtos simples, conforme a aplicação evolui precisa de uma arquitetura mais adequada, idealmente seguindo ou documentando padrões, aplicações web já foram feitas tantas vezes que emergiram padrões para nos auxiliar.

A origem do legado

Muitos sistemas são construído na mentalidade de projeto, mas sistemas são mais parecidos com serviços, eles interagem com protocolos, com ecossistemas, bibliotecas e serviços, além de melhorias na própria plataforma em que foram desenvolvidos, eventualmente algum desses pontos precisa de atualização.

Os motivos principais para um sistema ser considerado legado são

Dependências descontinuada

É a possibilidade mais remota, a não ser que uma tecnologia exótica com pouquíssimos usuários, se o planejamento foi bem feito durante a construção esse risco já deveria estar previsto.

Trabalhar com sistemas open source também mitiga bem esse risco, usualmente outros provedores desse serviço também costumam emergir para ocupar o lugar e em ultima instância você pode incorporar a rotina de manutenção desse sistema por conta própria.

Descaso com atualizações

Os softwares sempre tem novas versões, e existem razões para se preocupar em atualizá-los. A medida que a atualização de um sistema vai sendo postergada existe um efeito na segurança e outro pouco visível na produtividade, novas versões trazem novas soluções para os problemas, as documentações e tutoriais na internet começam a focar nas novidades.

Qualquer sistema com a versão abaixo da LTS deveria ser tratado como um risco de segurança e impacto de performance.

Aumento na complexidade do projeto

Existe na literatura técnica diversos registros de que ocorre um aumento exponencial da complexidade ao adicionar novos recursos a um sistema existente quando ele não possui uma boa arquitetura e seus débitos são acumulados.

Um projeto pode ter sido concebido de forma mal estruturada ou pode ter ficado assim após os autores originais terem saído. De qualquer forma não houve atenção e habilidade suficientes para acompanhar as agendas de atualizações dos sistemas.

Dividir para fracassar

A maioria dos sistemas não devem e não podem ser reescritos do zero. Qualidade não é um programa que pode ser instalado de maneira simples. Seu projeto chegou nesse estado e pode acontecer de novo até mesmo na fase inicial da instalação de um framework, desenvolvedores ruins costumam se escorar nessa solução e existe o risco de fazer um sistema pior que o primeiro.

É uma ideia comum pensar em abandonar a tecnologia atual e apostar na escrita de um sistema novo, e na teoria é uma tarefa trivial pois é possível fazer alguns CRUDs por dia, então supõem que é possível parar de dar manutenção e funcionalidades ao sistema antigo e começar um sistema novo. Um projeto isolado para substituir no final, a medida que o tempo passa mais demandas vão sendo impostas sobre o sistema antigo, então começa a briga por recursos de desenvolvimento.

Você incorre em dois problemas principais, você precisa entregar funcionalidades com a metade do contingente no sistema antigo, que é lento para implementar as coisas, e o novo sistema ainda não está pronto para produção.

Elevando os padrões

O maior efeito perceptível de incremento de qualidade é quando existe um consenso sobre. Satisfação dos desenvolvedores ao desenvolver, da gerencia sobre a produtividade e dos usuários quanto a confiabilidade, funcionalidade e performance do sistema.

Alguns pontos chave para tratar da qualidade da aplicação

Revisão de código

Os processos de revisão de código são de certo a parte mais importante pois é a partir da entrada de novos códigos que melhoramos ou pioramos o que existe, é preciso bloquear commits diretos para master/main, mesmo os desenvolvedores mais experientes não devem ter esse tipo de permissão. É necessário que outros desenvolvedores experientes na base de código avaliem, também é importante observar que se a nenhuma revisão aponta problemas e melhorias, a revisão não está sendo feita corretamente.

Implementação de pipelines

Pipelines integram nos eventos do repositório e podem executar ações para validar se testes automáticos da qualidade do sistema continuam passando, validam se a forma de escrita está de acordo com a definição da equipe (via linters), executam implantações em servidores de teste e produção.

Monitoramento de defeitos e exceções

Não basta esperar a crítica dos clientes, é necessário fazer um monitoramento proativo de problemas e reportar para os clientes antes que eles precisem comunicar o problema, isso estabelece uma confiança na ferramenta, ferramentas como Sentry, Bugsnag, Datadog, Raygun, etc. conseguem sumarizar os erros tanto do frontend quanto do backend para que o problema possa ser corrigido o mais rápido possível, também é importante tratar dos falso positivos para que não tire a visibilidade dos problemas reais.

Estilização de código

O PHP tem um padrão de estilização de código definido pela PSR-12, é uma boa prática segui-lo, mas também existem os padrões do Laravel, Symfony, e outros. É possível automatizar com o ecs ou phpcs, e no caso do Laravel, com o Laravel Pint.

Análise estática e refatoração automatizada

O PHP é uma linguagem interpretada, isso implica em só saber que um código está com problema (seja sintático ou lógico) durante a execução. IDEs mais recentes introduzem algum tipo de validação sintática através do Language Server Protocol, também existem ferramentas para conseguir fazer essa análise de forma estática como PHPStan e PSalm que podem aprimorar a qualidade do código e evita bugs antes mesmo de entrar em produção.

Para refatoração automatizada de código existem ferramentas como Rector e Phabric, com o Rector é possível migrar automaticamente entre versões do PHP e bases de código legada para os padrões mais recentes usando regras personalizadas, frameworks também costumam criar regras para o Rector facilitando a atualização.

Conclusão

O PHP é uma linguagem acessível mas exige uma atenção com qualidade assim como qualquer outra tecnologia para que seja produtiva e atenda as necessidade dos consumidores, ao atentar para se manter atualizado garantimos entregas, segurança e performance nos mantendo produtivos e competitivos mediante o mercado. Também é importante lembrar que assim como na engenharia tradicional, grandes saltos de produtividade advém de novas ferramentas e é importante incorporar o uso delas para se beneficiar.