Miks me vajame Symfony Polyfill'i (... ja miks me ei peaks seda tegema)

Enamikus kaasaegsetes PHP projektid, märkate tugevat sõltuvust programmi Symfony Polyfill raamatukogu. Selles artiklis selgitame mitte ainult seda, kuidas see töötab ja kuidas see on seotud Symfony projektid, kuid me süveneme ka probleemi ideesse, mida see püüab lahendada.

Natuke ajalugu

PHP oli üsna pikka aega halvas seisus. See oli 2005. aastal, kui Andrei Zmievski alustas projekt et tuua Unicode'i emakeelne tugi PHP tõttu vastuolulised arvustused ja paljud mured, et PHP läheb vales suunas. Areng PHP 6.x algas. Kuid see ei saanud kunagi valmis - ja see on lugu teise päeva jaoks. 10 aastat hiljem, kuskil 2014 ja 2015 vahel, alustasid Dmitri Stogov, Xinchen Hui ja Nikita Popov. phpng - projekt, mis optimeeris ja muutis ümber sisemise Zend Engine'i, mida kasutab PHP.

>_ Sündis PHP 7

Ja viimastel aastatel, PHP kasvab kiiremini kui kunagi varem, praegu on stabiilne versioon 8.1.

Keele uute funktsioonide kiire arengu tõttu ei pidanud mitte ainult arendajad, vaid ka infrastruktuuri- ja hostinguteenuse pakkujad kohanema nende muudatustega.

Et meie, arendajad, saaksime kasutada meie armastatud programmeerimiskeele uusimaid ja parimaid funktsioone. Symfony Polyfill sündis projekt.

Symfony Polyfill ja selle funktsioon

See projekt on backports funktsioonid, mis on leitud viimases PHP versioonid ning pakub ühilduvuskihti mõnede laienduste ja funktsioonide jaoks. See on mõeldud kasutamiseks, kui ülekantavus üle kogu PHP versioonid ja laiendused on soovitud.

See on puhas kirjeldus Symfony Polyfill kuid mida see tähendab?

Kiiresti areneva PHP keel ja ISPde tarkvara kohandamise väljapoole astet, on enamik arendajaid seisnud lihtsa valiku ees:

• Arendajana loodan ma rakendusi vanemas versioonis PHP ja ei saa kasutada keele uusimaid funktsioone või
• Arendajana loodan kaasaegse rakenduse, kasutades uusimat versiooni PHP.

Kuid nad pidid säilitama ühilduvuse teiste tööriistade ja teenustega, mida juba kasutatakse nii kood ja infrastruktuuri poolel - peaaegu alati kasutades vanemaid versioone PHPKas ma pean mainima, lugupeetud lugeja, nende kahe lahenduse nn "lõbufaktorit"?

Et lihtsustada arendajate tööd, koostas avatud lähtekoodiga kogukond 2015. aastal Polyfilli esimene stabiilne versioon number 1.0. Arendajate elu muutus lihtsamaks ja võib öelda, et Symfony Polyfill lahendas paljud probleemid, näiteks koodi teisaldatavuse erinevate platvormide vahel, PHP versioon erinevused ning muutis rakenduste refaktooringu ja tehnoloogiavõlgade vähendamise palju lihtsamaks.

Kahjuks ei saa kõiki probleeme lahendada ühe vahendiga.

Probleemid, mis on seotud mitme keskkonnaversiooni säilitamisega

Keerulise IT-projektid, on erinevate klientide/kontorite/osakondade jaoks erinevate keskkonnaversioonide haldamine tavaline protseduur. Selle tulemuseks on vajadus arendada samaaegselt palju erinevaid rakenduste harusid, millel on sageli erinevad funktsionaalsed nõuded ja oma tõmbekeskkond. Ma olen palju kordi seisnud silmitsi probleemiga, mis on seotud sama rakenduse hooldamisega erinevate klientide jaoks erinevates PHP5 / PHP7 keskkondades, ning hulk probleeme, mis on seotud raamatukogude või nende sõltuvuste ühildamatusega erinevate versioonide puhul, on lihtsalt lahendamatu, kasutades ainult Symfony Polyfill.

Oskuste erinevus arendusmeeskonna liikmete vahel

Tänu kiirele kasvule funktsioonide sisseehitatud PHPpaljud arendajad ei ole muutuste tempoga sammu pidanud. Paljud funktsioonid, mida pakuvad kõrgemad versioonid PHP on lihtne saavutada väliste raamatukogude abil või arendajad lihtsalt ei vajanud uusi funktsioone, nagu näiteks PHP Kiudained. Valides meeskond liikmed, on hea mõte tagada, et oskused oleksid vastavuses või et koodi tarnimise protsess oleks järjepidevam staatilise analüüsi vahendite ja versiooniregressiooni vigade varajase tuvastamise abil.

Vastumeelsus muutuste suhtes

Uute keeleomaduste kasutuselevõtt on endiselt üsna madal ja PHP 5 üle 24% osakaal näitab selgelt, et veerand PHP projektidest töötab versiooniga 7.x või madalama versiooniga., mille turvatoetus lõpetatakse 6. detsembril 2022. See tähendab, et selle postituse kirjutamise ajal on aasta lõpuks üle 25% PHP-põhistest veebiprojektidest potentsiaalselt haavatavad kõigi uute turvaaukude suhtes. "Kui see töötab, siis miks peaksime vaeva nägema"?

Kokkuvõte

Me peaksime kohanema keeleliste muudatustega võimalikult kiiresti ja kasutama võimalikult kiiresti uusimaid lahendusi. Legacy-projekti võimaliku migratsiooni käigus tasub kaasata Symfony Polyfill abivahendina ja kasutades selliseid tehnikaid nagu Strangler Pattern ja praegu moes olev BDD metoodika, mida on vapustavalt lihtne rakendada, et Symfony raamistik. Kas me oleme tõesti sunnitud kasutama Symfony Polyfill?

Loe edasi:

PHP arendus: 5 asja, mida peaksite teadma

7 idufirmat & Scaleup'i, mis raputavad turuskeene 2022. aastal

PHP arendus. Symfony konsooli komponent - näpunäited ja nipid