Waarom hebben we Symfony Polyfill nodig (... en waarom niet)?

In de meeste moderne PHP projectenzul je een grote afhankelijkheid van de Symfony Polyfill bibliotheek. In dit artikel leggen we niet alleen uit hoe het werkt en hoe het gerelateerd is aan Symfony-projectenmaar we zullen ook dieper ingaan op het idee van het probleem dat het probeert op te lossen.

Een beetje geschiedenis

PHP was er lange tijd slecht aan toe. Het was 2005 toen Andrei Zmievski een project om Unicode-ondersteuning te bieden voor PHP als gevolg van gemengde recensies en veel zorgen dat PHP gaat de verkeerde kant op. Ontwikkeling van PHP 6.x begonnen. Maar het werd nooit afgemaakt - en dat is een verhaal voor een andere dag. 10 jaar later, ergens tussen 2014 en 2015, begonnen Dmitry Stogov, Xinchen Hui en Nikita Popov met phpng - project dat de interne Zend Engine die wordt gebruikt door PHP.

>_ De PHP 7 is geboren

En voor de afgelopen jaren, PHP groeit sneller dan ooit en heeft momenteel de stabiele versie 8.1.

Door de snelle ontwikkeling van nieuwe functies in taal moesten niet alleen ontwikkelaars zich aanpassen aan die veranderingen, maar ook infrastructuur en hosting service providers.

Om ervoor te zorgen dat wij, ontwikkelaars, de nieuwste en beste functies van onze geliefde programmeertaal kunnen gebruiken Symfony Polyfill project geboren.

Symfony Polyfill en zijn functie

Dit project backports functies gevonden in de nieuwste PHP versies en biedt compatibiliteitslagen voor sommige uitbreidingen en functies. Het is bedoeld om gebruikt te worden wanneer overdraagbaarheid tussen PHP versies en uitbreidingen gewenst is.

Dit is een pure beschrijving van Symfony Polyfill maar wat betekent dat?

Door de snel evoluerende PHP taal en de niet-stapsgewijze softwareaanpassing van ISP's, stonden de meeste ontwikkelaars voor een eenvoudige keuze:

• Als ontwikkelaar maak ik applicaties in een oudere versie van PHP en de nieuwste functies van de taal niet kan gebruiken, of
• Als ontwikkelaar maak ik een moderne applicatie met de nieuwste versie van PHP.

Maar ze moesten compatibel blijven met andere tools en services die al werden gebruikt op de code en infrastructuurkant - bijna altijd met oudere versies van PHPBeste lezer, moet ik nog de zogenaamde 'funfactor' van deze twee oplossingen noemen?

Om de weg voor ontwikkelaars te vergemakkelijken, heeft de Open Source gemeenschap in 2015 de eerste stabiele versie van Polyfill genummerd 1.0. Het leven van ontwikkelaars werd eenvoudiger en je zou kunnen zeggen dat Symfony Polyfill een groot aantal problemen heeft opgelost, zoals de overdraagbaarheid van code tussen verschillende platformen, Versie PHP verschillen en maakte het refactoren van applicaties en het verminderen van de technologieschuld veel eenvoudiger.

Helaas kunnen niet alle problemen met één tool worden opgelost.

Problemen met het onderhouden van meerdere versies van de omgeving

Voor complexe IT-projectenHet onderhouden van verschillende versies van omgevingen voor verschillende klanten/branches/afdelingen is een veel voorkomende procedure. Dit resulteert in de noodzaak om veel verschillende takken van applicaties tegelijkertijd te ontwikkelen, vaak met verschillende functionele eisen en met hun eigen tractie. Ik ben vele malen geconfronteerd met het probleem van het onderhouden van dezelfde applicatie voor verschillende klanten op verschillende PHP5 / PHP7-omgevingen en de veelheid van problemen met betrekking tot de incompatibiliteit van bibliotheken of hun afhankelijkheden voor verschillende versies is gewoon onoplosbaar met behulp van slechts Symfony Polyfill.

De vaardigheidskloof tussen leden van het ontwikkelingsteam

Door de snelle groei van functies ingebouwd in PHPVeel ontwikkelaars hebben het tempo van de veranderingen niet bijgehouden. Veel van de functies die in hogere versies van PHP eenvoudig te bereiken zijn met externe bibliotheken, of ontwikkelaars hadden de nieuwe functies gewoon niet nodig, zoals PHP Vezels. Bij het selecteren van team leden is het een goed idee om ervoor te zorgen dat de vaardigheden op elkaar zijn afgestemd of dat het opleveringsproces van de code consistenter wordt gemaakt door statische analysetools en vroegtijdige detectie van fouten bij versie-regressie.

Tegenzin om te veranderen

De adoptie van nieuwe taalfuncties is nog steeds vrij laag en PHP 5's over 24% aandeel laat duidelijk zien dat een kwart van de PHP projecten draaien versies lager dan 7.xwaarvan de beveiligingsondersteuning op 6 december 2022 wordt beëindigd. Dit betekent dat op het moment van schrijven van dit bericht, meer dan 25% van PHP-gebaseerde webprojecten potentieel kwetsbaar zullen zijn voor alle nieuwe beveiligingsproblemen tegen het einde van het jaar. "Als het werkt, waarom zouden we er dan moeite voor doen?

Conclusie

We moeten ons zo snel mogelijk aanpassen aan taalveranderingen en zo snel mogelijk de nieuwste oplossingen gebruiken. Tijdens een mogelijke migratie van een legacyproject is het de moeite waard om het volgende op te nemen Symfony Polyfill als helper en met behulp van technieken zoals het Strangler Pattern en de momenteel modieuze BDD-methodologie die fantastisch eenvoudig is toe te passen op de Symfony raamwerk. Dus zijn we echt gedwongen om Symfony Polyfill?

Lees meer:

PHP Ontwikkeling: 5 dingen die je moet weten

7 Startups & Scaleups die de markt zullen doen schudden in 2022

PHP Ontwikkeling. Symfony Console Component - Tips & Trucs