Porque é que precisamos do Symfony Polyfill (... e porque é que não devemos)

Na maioria dos modernos PHP projectos, notará uma forte dependência do Symfony Polyfill biblioteca. Neste artigo, explicaremos não só como funciona e como se relaciona com Projectos Symfonymas também vamos aprofundar a ideia do problema que tenta resolver.

Um pouco de história

PHP esteve em mau estado durante muito tempo. Foi em 2005 que Andrei Zmievski iniciou um projeto de projeto para oferecer suporte Unicode nativo para PHP devido a críticas mistas e muitas preocupações de que PHP está a seguir o caminho errado. Desenvolvimento de PHP 6.x começou. Mas nunca foi terminado - e essa é uma história para outro dia. 10 anos depois, algures entre 2014 e 2015, Dmitry Stogov, Xinchen Hui e Nikita Popov começaram o phpng - projeto que otimizou e refatorou o Zend Engine interno usado pelo PHP.

>_ Nasceu o PHP 7

E nos últimos anos, PHP está a crescer mais depressa do que nunca, encontrando-se atualmente na versão estável 8.1.

Devido ao rápido desenvolvimento de novas funcionalidades na linguagem, não só os programadores tiveram de se adaptar a essas alterações, como também as infra-estruturas e os fornecedores de serviços de alojamento.

Para garantir que nós, programadores, possamos utilizar as melhores e mais recentes funcionalidades da nossa querida linguagem de programação Symfony Polyfill nasceu o projeto.

Symfony Polyfill e a sua função

Este projeto suporta funcionalidades encontradas na última versão do Versões PHP e fornece camadas de compatibilidade para algumas extensões e funções. Destina-se a ser utilizado quando a portabilidade entre Versões PHP e extensões.

Esta é uma descrição pura de Symfony Polyfill mas o que é que isso significa?

Devido à rápida evolução da Língua PHP e a personalização de software fora de controlo dos ISPs, a maioria dos programadores viu-se confrontada com uma escolha simples:

• Como programador, crio aplicações numa versão mais antiga do PHP e não pode utilizar as caraterísticas mais recentes da língua, ou
• Como programador, crio uma aplicação moderna utilizando a versão mais recente do PHP.

Mas tinham de manter a compatibilidade com outras ferramentas e serviços já utilizados tanto no código e de infra-estruturas - quase sempre utilizando versões mais antigas do PHPSerá necessário mencionar, caro leitor, o chamado "fator diversão" destas duas soluções?

Para facilitar o trabalho dos programadores, a comunidade de código aberto criou em 2015 a primeira versão estável do Polyfill numerada 1.0. A vida dos programadores tornou-se mais fácil e pode dizer-se que o Symfony Polyfill resolveu uma série de problemas, como a portabilidade do código entre diferentes plataformas, Versão PHP e tornou muito mais fácil a refacção de aplicações e a redução da dívida tecnológica.

Infelizmente, nem todos os problemas podem ser resolvidos com uma única ferramenta.

Problemas associados à manutenção de várias versões do ambiente

Para os complexos Projectos de TINa atualidade, a manutenção de diferentes versões de ambientes para diferentes clientes/filiais/departamentos é um procedimento comum. Isto resulta na necessidade de desenvolver muitos ramos diferentes de aplicações ao mesmo tempo, muitas vezes com requisitos funcionais diferentes e com a sua própria tração. Já me deparei muitas vezes com o problema de manter a mesma aplicação para diferentes clientes em diferentes ambientes PHP5 / PHP7 e a multiplicidade de problemas relacionados com a incompatibilidade de bibliotecas ou suas dependências para diferentes versões é simplesmente insolúvel utilizando apenas Symfony Polyfill.

A diferença de competências entre os membros da equipa de desenvolvimento

Devido ao rápido crescimento das funcionalidades incorporadas no PHPNo entanto, muitos programadores não acompanharam o ritmo da mudança. Muitas das funcionalidades oferecidas nas versões superiores do PHP são fáceis de obter com bibliotecas externas, ou os programadores simplesmente não precisavam das novas funcionalidades, tais como Fibras PHP. Ao selecionar equipa membros, é uma boa ideia certificar-se de que as competências são compatíveis ou que o processo de entrega de código é mais consistente através de ferramentas de análise estática e da deteção precoce de erros de regressão de versão.

Relutância em mudar

A adoção de novas caraterísticas linguísticas é ainda bastante reduzida e PHP 5 sobre a quota de 24% mostra claramente que um quarto dos projectos PHP estão a executar versões inferiores a 7.xque terá seu suporte de segurança encerrado em 6 de dezembro de 2022. Isto significa que, no momento em que este post é escrito, mais de 25% de projectos Web baseados em PHP estarão potencialmente vulneráveis a todas as novas vulnerabilidades de segurança até ao final do ano. "Se funciona, porque é que nos havemos de incomodar?

Conclusão

Devemos adaptar-nos às alterações linguísticas o mais rapidamente possível e utilizar as soluções mais recentes o mais rapidamente possível. Durante uma possível migração de um projeto legado, vale a pena incluir Symfony Polyfill como auxiliar e utilizando técnicas como o Strangler Pattern e a metodologia BDD atualmente em voga, que é fabulosamente fácil de aplicar ao Estrutura Symfony. Então, somos mesmo obrigados a utilizar Symfony Polyfill?

Ler mais:

Desenvolvimento do PHP: 5 coisas que você deve saber

7 Startups e Scaleups que vão abalar o cenário do mercado em 2022

Desenvolvimento PHP. Componente de Consola Symfony - Dicas e Truques