Mudar sempre é preciso, porém mudar nunca é fácil, ainda mais quando se trata de mudar uma base tecnológica que vem se aprimorando já a alguns anos, porém, mudar é preciso.
Já dizia Dom Hélder Câmara que é preciso mudar para permanecer o mesmo.
“Feliz de quem entende que é preciso mudar muito pra ser sempre o mesmo.” – Dom Hélder Câmara
Em tecnologia, esse tipo de mudança implica em modificar processos, melhorar e desenvolver novas tecnologias, habilidades e conhecimentos, para continuar sendo uma empresa de tecnologia que entende o que faz.
O processo é constante já que tecnologia muda a todo momento. Contudo, há algumas partes que permanecem por mais tempo do que as outras. Essas partes compõe, pelo menos parcialmente, as bases do negócio.
Pra nós, uma das bases que utilizamos chegou no momento de mudança, de um necessário upgrade a fim de mantê-la viva e funcional. Essa base é o PHP.
Nos bastidores de uma migração
Já tem algum tempo que a nova versão do PHP – a 7 – está disponível, inclusive com suporte no web-server que utilizamos na maioria dos nossos projetos. Porém, como tudo que é novo e tende a quebrar no início, resolvemos esperar a tecnologia estabilizar antes mesmo de considerar migrar a base de código de PHP 5 para PHP 7.
Um pouco disso é cautela. Decorre da experiência acumulada em anos de trabalho com desenvolvimento de software. Um pouco é comodismo. Imagina ter que ‘trocar’ milhares e milhares de linhas de código, métodos, classes e funções para um novo padrão assim de cara. O desânimo logo vem à mente, antes mesmo de se começar!
Mas mudar é preciso e se você não muda, ou evolui, por livre e espontânea vontade, irá por livre e espontânea pressão. Conosco foi um pouco das duas coisas.
Com o framework que utilizamos para fazer testes unitários em código PHP terminando o suporte ao PHP 5 em 2018, tivemos a necessidade de considerar a migração para o PHP 7. Caso contrário, eventualmente ficaríamos sem conseguir efetivamente utilizar essa tecnologia e isso não é uma boa opção.
É claro que a versão antiga do framework ainda existe, é muito estável e poderíamos continuar utilizando-a. Porém, teríamos que correr o risco de no futuro precisarmos de uma função que não estava implementada e termos que implementá-la nós mesmos. Isso não é um problema, óbvio, mas pode gerar custos indesejados.
Da mesma maneira, é possível que a versão baseada no php 7 evolua ao ponto de oferecer novos métodos de teste, muito superiores aos existentes na versão do php 5. Isso tornaria a migração muito atrativa. Então, adotando a política do “better late than never“, resolvemos estudar a nova versão da linguagem e ver o que poderíamos tirar de proveito.
E aqui vem o “livre espontânea vontade”. O PHP 7 não é um php feito do zero, que ignora o que tem antes. Ao contrário, é apenas uma evolução da linguagem, adicionando novas funcionalidades.
Sendo assim, poderíamos simplesmente adotar uma forma ‘híbrida’ entre o PHP 5 e o 7, mantendo a maior compatibilidade possível entre as duas versões. O efeito colateral seria ignorar as algumas das novas funcionalidades disponíveis na versão 7.
Embora esse seja o caminho mais fácil, pode não ser o mais adequado. Afinal, se teremos o custo de implementar uma migração, porque não fazê-la completa? Outra questão válida é se as funcionalidades que teríamos que ignorar trariam algum bom benefício a ponto de não ser muito interessante ignorá-las.
No caso do php 7, há sim prejuízo em ignorar o que tem de novo. Mas pra entender isso, preciso listar quais as vantagens do novo php que consideramos válidas pra nós.
Vantagens do novo php
De fato há algumas novas funcionalidades do PHP 7 que já sentíamos falta a algum tempo. Citando:
Tipagem de retorno em métodos e funções
Uma das coisas que todo bom desenvolvedor PHP gosta é a tipagem dinâmica presente na linguagem. É ‘uma mão na roda’! Entretanto, uma das coisas que pelo menos nós aqui sempre sentimos falta era uma forma de identificar de maneira mais simples o retorno de um método ou função.
Há casos em que esse tipo de coisa não tem valor. Ex: se está lendo um número de um formulário, tanto faz se ele está como int/float ou string. Desde que a entrada esteja correta (seja um conjunto de dígitos referentes a número), irá processar a informação do mesmo jeito.
Porém, há situações em que você precisa de fato saber o tipo de um dado. Ex: está utilizando uma biblioteca de terceiros que realiza alguma operação e te retorna algo. Se o retorno não é informado na documentação a escolha é ler o código do método ou testar o retorno. Essa definitivamente não é a melhor solução pro problema.
Como nem tudo são rosas, há uma consequência para o uso desse tipo de funcionalidade. Se o método/função retorna mais de um tipo de valor, a funcionalidade irá complicar sua vida.
Para quem tem muito código já escrito e funcionando com múltiplos retorno, será complicado o uso da nova funcionalidade. Porém, nós não vemos essa questão como algo ruim. Afinal, em linguagens de tipagem forte (C, C++, C#, Java, etc) essa situação existe e achamos soluções pra elas lá. Então se existem soluções fora do PHP, podemos trazê-las para o PHP.
Essa foi a nossa escolha e por isso consideramos a nova funcionalidade uma vantagem necessária.
Na versão 7.2 do php essa tipagem do retorno ainda passou a reconhecer o retorno nulo. Pelo menos pra nós, melhorou ainda mais o que já estava bom.
Novos operadores
Outra boa novidade foi a implementação de novos operadores que pelo menos tornam a codificação mais fluída.
O primeiro deles é o operador para teste de valor nulo. Antes esse teste era feito com a função is_null. Agora basta utilizar ?? em uma expressão de teste que resolve.
O outro operador que achamos legal é o “navinha”, o <=> que serve para comparar informações. Antes, isso era resolvido através do uso de if’s e else’s aninhados, o que fazia o código ficar um pouco longo.
Essa redução de tamanho de código permitida pelos novos operadores é muito útil. Pra quem escreve pouco código ou métodos pouco longos, isso talvez não faça muita diferença. Porém, em sistemas com milhares de linhas de código, cada linha conta. Por isso, gostamos e muito dessa novidade
Unificação entre erros e exceções
A última das boas novidades que encontramos é a unificação de erros e exceções. No php 5 erro e exceção eram coisam distintas, o que nos demandava tratá-los separadamente. O resultado era código ainda mais longo.
Com a unificação no php 7, agora podemos usar um try-catch pra resolver ambos os casos. Isso permite não só códigos menores, o que como escrevi acima é muito importante em projetos mais complexos, como também códigos mais elegantes.
Resumindo
O novo php melhorou, pra nós:
1 – o tratamento dos retornos das funções e métodos, nos desobrigando a testar o retorno ou ler o código fonte (quando disponível) em caso de dúvidas.
2 – a economia de código com novos operadores e a unificação no tratamento de erros e exceções
Pouco né? Nem tanto!
Em projetos pequenos é difícil perceber o valor dessas “pequenas” coisas. Porém quando precisa integrar seu software com o de terceiros ou mesmo dar manutenção em um código que escreveu tempos atrás, eu te garanto que irá gostar dessas mudanças “cosméticas”.
Como manutenibilidade de um projeto a longo prazo é sempre uma boa preocupação antes sequer de escrever a primeira linha de código, novidades que melhoram esse aspecto são sempre muito bem vindas.
Um pouco de maturidade no negócio
Embora a nova versão do PHP tenha as importantes vantagens que citei, não dá para simplesmente ‘reinventar a roda’ todo dia. Os softwares dos nossos clientes estão desenvolvidos no padrão antigo (php 5). Alguns deles são extensos demais para mesmo considerarmos a atualização pro padrão novo sem implicar em custos pro cliente.
Isso nos gerou um impasse, porque decidimos usar o novo padrão, mas não podemos aplicá-lo em “tudo quanto é canto”.
A solução que encontramos foi aplicar o novo padrão apenas para os novos projetos e produtos. Assim precisaremos continuar mantendo código em padrão antigo ao mesmo tempo em que usamos o novo padrão nos novos projetos.
Um pouco confuso claro, mas a longo prazo traz muitos benefícios. Além de reduzir consideravelmente a geração de mais código no padrão antigo, podemos experimentar e amadurecer a nova tecnologia, através das novas implementações, para depois até tentar convencer os clientes a atualizar. As vezes, o próprio corte do suporte da tecnologia, como foi com o PHP 4, nos apresenta uma oportunidade para o upgrade.
Esse tipo de análise mostra maturidade. Eu não posso falar dos outros mas eu já fui muito xiita quanto a tecnologia. Sempre queria a melhor solução disponível e por melhor entenda, a melhor computacionalmente.
Acontece que no mercado as coisas não funcionam assim e trocar tecnologias para a última versão nem sempre é a melhor das opções. A maioria dos casos requer estudo e paciência para tal e isso, felizmente, já aprendemos.