Hvorfor trenger vi Symfony Polyfill (... og hvorfor vi ikke bør gjøre det)

I de fleste moderne PHP prosjektervil du legge merke til en stor avhengighet av Symfony Polyfill bibliotek. I denne artikkelen forklarer vi ikke bare hvordan det fungerer, men også hvordan det er knyttet til Symfony-prosjektermen vi vil også gå dypere inn i ideen om problemet den forsøker å løse.

Litt historie

PHP var i dårlig forfatning i ganske lang tid. Det var i 2005 at Andrei Zmievski startet en prosjekt for å gi opprinnelig Unicode-støtte for PHP på grunn av blandede anmeldelser og mange bekymringer for at PHP går i feil retning. Utviklingen av PHP 6.x ble påbegynt. Men den ble aldri ferdig - og det er en historie for en annen dag. 10 år senere, et sted mellom 2014 og 2015, startet Dmitry Stogov, Xinchen Hui og Nikita Popov phpng - prosjekt som optimaliserte og refaktoriserte den interne Zend Engine som brukes av PHP.

>_ PHP 7 ble født

Og for de siste årene, PHP vokser raskere enn noensinne, og er nå i stabil versjon 8.1.

På grunn av den raske utviklingen av nye funksjoner i språket var det ikke bare utviklerne som måtte tilpasse seg endringene, men også leverandører av infrastruktur og hostingtjenester.

For å sikre at vi utviklere kan bruke de nyeste og beste funksjonene i vårt kjære programmeringsspråk Symfony Polyfill prosjektet ble født.

Symfony Polyfill og dens funksjon

Dette prosjektet tilbakeporterer funksjoner som finnes i den nyeste PHP-versjoner og tilbyr kompatibilitetslag for enkelte utvidelser og funksjoner. Den er ment å brukes når portabilitet på tvers av PHP-versjoner og utvidelser er ønskelig.

Dette er en ren beskrivelse av Symfony Polyfill Men hva betyr det?

På grunn av den raske utviklingen PHP språk og den utradisjonelle programvaretilpasningen hos Internett-leverandørene, har de fleste utviklere blitt stilt overfor et enkelt valg:

• Som utvikler lager jeg applikasjoner i en eldre versjon av PHP og ikke kan bruke de nyeste funksjonene i språket, eller
• Som utvikler lager jeg en moderne applikasjon ved hjelp av den nyeste versjonen av PHP.

Men de måtte opprettholde kompatibilitet med andre verktøy og tjenester som allerede var i bruk både på kode og infrastruktursiden - nesten alltid ved hjelp av eldre versjoner av PHPTrenger jeg å nevne, kjære leser, den såkalte "morsomhetsfaktoren" ved disse to løsningene?

For å gjøre det enklere for utviklere, utviklet Open Source-fellesskapet i 2015 den første stabile versjonen av Polyfill nummerert 1.0. Utviklernes liv ble enklere, og man kan si at Symfony Polyfill løste en rekke problemer, som for eksempel kodeportabilitet mellom ulike plattformer, PHP-versjon forskjeller, og gjorde det mye enklere å refaktorisere applikasjoner og redusere teknologigjelden.

Dessverre er det ikke alle problemer som kan løses med ett verktøy.

Problemer forbundet med å vedlikeholde flere versjoner av miljøet

For komplekse IT-prosjekterDet er vanlig å vedlikeholde ulike versjoner av miljøer for ulike kunder/bransjer/avdelinger. Dette resulterer i behovet for å utvikle mange forskjellige grener av applikasjoner samtidig, ofte med forskjellige funksjonelle krav og med sin egen trekkraft. Jeg har mange ganger møtt problemet med å vedlikeholde den samme applikasjonen for forskjellige kunder på forskjellige PHP5 / PHP7-miljøer, og de mange problemene knyttet til inkompatibiliteten til biblioteker eller deres avhengigheter for forskjellige versjoner er rett og slett uløselige ved å bare bruke Symfony Polyfill.

Kompetansegapet mellom medlemmene i utviklingsteamet

På grunn av den raske veksten av funksjoner innebygd i PHPhar mange utviklere ikke holdt tritt med utviklingen. Mange av funksjonene som tilbys i høyere versjoner av PHP er enkle å oppnå med eksterne biblioteker, eller utviklerne hadde rett og slett ikke behov for de nye funksjonene, som for eksempel PHP-fibre. Når du velger team er det en god idé å sørge for at kompetansen er tilpasset hverandre, eller at kodeleveranseprosessen gjøres mer konsistent ved hjelp av statiske analyseverktøy og tidlig oppdagelse av feil ved versjonsregresjon.

Motvilje mot endring

Bruken av nye språkfunksjoner er fortsatt ganske lav, og PHP 5s andel på over 24% viser tydelig at En fjerdedel av PHP-prosjektene kjører lavere versjoner enn 7.x, som vil få sikkerhetsstøtten terminert 6. desember 2022. Dette betyr at når dette innlegget skrives, vil over 25% av PHP-baserte webprosjekter være potensielt sårbare for alle nye sikkerhetshull innen utgangen av året. "Hvis det fungerer, hvorfor skal vi bry oss?"

Konklusjon

Vi bør tilpasse oss språkendringer så raskt som mulig og ta i bruk de nyeste løsningene så snart som mulig. Under en eventuell migrering av et Legacy-prosjekt er det verdt å inkludere Symfony Polyfill som et hjelpemiddel og ved hjelp av teknikker som Strangler Pattern og den for tiden moteriktige BDD-metodikken, som er fabelaktig enkel å bruke på Rammeverket Symfony. Så er vi virkelig tvunget til å bruke Symfony Polyfill?

Les mer om dette:

PHP Utvikling: 5 ting du bør vite

7 oppstartsbedrifter og vekstbedrifter som vil ryste markedsscenen i 2022

PHP Utvikling. Symfony-konsollkomponent - tips og triks