Hvorfor har vi brug for Symfony Polyfill (... og hvorfor vi ikke bør)

I de fleste moderne PHP projektervil du bemærke en stor afhængighed af Symfony Polyfill bibliotek. I denne artikel forklarer vi ikke kun, hvordan det fungerer, og hvordan det hænger sammen med Symfony-projektermen vi vil også gå dybere ind i ideen om det problem, den forsøger at løse.

En lille smule historie

PHP var i dårlig form i lang tid. Det var i 2005, at Andrei Zmievski startede en projekt for at bringe indbygget Unicode-understøttelse til PHP på grund af blandede anmeldelser og mange bekymringer om, at PHP går den forkerte vej. Udvikling af PHP 6.x blev påbegyndt. Men det blev aldrig færdigt - og det er en historie til en anden dag. 10 år senere, et sted mellem 2014 og 2015, startede Dmitry Stogov, Xinchen Hui og Nikita Popov phpng - projekt, der optimerede og refaktoriserede den interne Zend Engine, der bruges af PHP.

>_ PHP 7 blev født

Og for de seneste år, PHP vokser hurtigere end nogensinde og er nu i en stabil version 8.1.

På grund af den hurtige udvikling af nye funktioner i sproget var det ikke kun udviklere, der skulle tilpasse sig disse ændringer, men også leverandører af infrastruktur og hostingtjenester.

For at sikre, at vi udviklere kan bruge de nyeste og bedste funktioner i vores elskede programmeringssprog Symfony Polyfill projekt blev født.

Symfony Polyfill og dens funktion

Dette projekt bagudporterer funktioner, der findes i den seneste PHP-versioner og giver kompatibilitetslag for nogle udvidelser og funktioner. Den er beregnet til at blive brugt, når portabilitet på tværs af PHP-versioner og udvidelser er ønsket.

Dette er en ren beskrivelse af Symfony Polyfill Men hvad betyder det?

På grund af den hurtige udvikling PHP sprog og ISP'ernes manglende softwaretilpasning har de fleste udviklere stået over for et simpelt valg:

• Som udvikler laver jeg applikationer i en ældre version af PHP og kan ikke bruge de nyeste funktioner i sproget, eller
• Som udvikler skaber jeg en moderne applikation ved hjælp af den nyeste version af PHP.

Men de var nødt til at bevare kompatibiliteten med andre værktøjer og tjenester, der allerede blev brugt både på Kode og infrastruktursiden - næsten altid med ældre versioner af PHPBehøver jeg at nævne, kære læser, den såkaldte 'fun factor' ved disse to løsninger?

For at lette vejen for udviklere skabte Open Source-fællesskabet i 2015 Den første stabile version af Polyfill er nummereret 1.0. Udviklernes liv blev lettere, og man kan sige, at Symfony Polyfill løste en lang række problemer som f.eks. kodeportabilitet mellem forskellige platforme, PHP-version forskelle og gjort refaktorering af applikationer og reduktion af teknologigæld meget nemmere.

Desværre er det ikke alle problemer, der kan løses med ét værktøj.

Problemer med at vedligeholde flere versioner af miljøet

For komplekse IT-projekterAt vedligeholde forskellige versioner af miljøer til forskellige kunder/brancher/afdelinger er en almindelig procedure. Dette resulterer i behovet for at udvikle mange forskellige grene af applikationer på samme tid, ofte med forskellige funktionelle krav og med deres egen trækkraft. Jeg har mange gange stået over for problemet med at vedligeholde den samme applikation til forskellige kunder på forskellige PHP5 / PHP7-miljøer, og de mange problemer i forbindelse med inkompatibiliteten af biblioteker eller deres afhængigheder for forskellige versioner er simpelthen uløselige ved kun at bruge Symfony Polyfill.

Kompetencegabet mellem medlemmerne af udviklingsteamet

På grund af den hurtige vækst i funktioner indbygget i PHPMange udviklere har ikke fulgt med i forandringens tempo. Mange af de funktioner, der tilbydes i højere versioner af PHP er nemme at opnå med eksterne biblioteker, eller udviklerne havde simpelthen ikke brug for de nye funktioner, som f.eks. PHP-fibre. Når du vælger hold medlemmer, er det en god idé at sikre, at færdighederne matcher, eller at kodeleveringsprocessen gøres mere konsekvent ved hjælp af statiske analyseværktøjer og tidlig opdagelse af versionsregressionsfejl.

Modvilje mod forandring

Anvendelsen af nye sprogfunktioner er stadig ret lav, og PHP 5's andel på over 24% viser tydeligt, at En fjerdedel af PHP-projekterne kører versioner, der er lavere end 7.x, hvis sikkerhedsstøtte ophører den 6. december 2022. Det betyder, at i skrivende stund vil over 25% af PHP-baserede webprojekter være potentielt sårbare over for alle nye sikkerhedshuller inden årets udgang. "Hvis det virker, hvorfor skal vi så bekymre os"?

Konklusion

Vi bør tilpasse os sprogændringer så hurtigt som muligt og bruge de nyeste løsninger så hurtigt som muligt. Under en mulig migrering af et Legacy-projekt er det værd at medtage Symfony Polyfill som en hjælper og ved at bruge teknikker som Strangler Pattern og den for tiden moderne BDD-metodologi, som er fantastisk nem at anvende på Symfony-rammeværk. Så er vi virkelig tvunget til at bruge Symfony Polyfill?

Læs mere om det:

PHP udvikling: 5 ting, du bør vide

7 startups og scaleups, der vil ryste markedspladsen i 2022

PHP udvikling. Symfony-konsolkomponent - tips og tricks