Varför behöver vi Symfony Polyfill (... och varför vi inte borde göra det)

I de flesta moderna PHP projektkommer du att märka att det finns ett stort beroende av Symfony Polyfill bibliotek. I den här artikeln förklarar vi inte bara hur det fungerar och hur det förhåller sig till Symfony-projektmen vi kommer också att gå djupare in på idén om det problem som den försöker lösa.

Lite historia

PHP var i dåligt skick under en ganska lång tid. Det var 2005 som Andrei Zmievski startade en projekt för att ge inbyggt Unicode-stöd för PHP på grund av blandade recensioner och många farhågor om att PHP är på väg åt fel håll. Utvecklingen av PHP 6.x påbörjades. Men det blev aldrig färdigt - och det är en historia för en annan dag. 10 år senare, någon gång mellan 2014 och 2015, startade Dmitry Stogov, Xinchen Hui och Nikita Popov phpng - projekt som optimerade och omarbetade den interna Zend Engine som används av PHP.

>_ PHP 7 var född

Och för de senaste åren, PHP växer snabbare än någonsin och har för närvarande en stabil version 8.1.

På grund av den snabba utvecklingen av nya funktioner i språket var det inte bara utvecklarna som var tvungna att anpassa sig till dessa förändringar, utan även leverantörer av infrastruktur och hostingtjänster.

För att säkerställa att vi utvecklare kan använda de nyaste och bästa funktionerna i vårt älskade programmeringsspråk Symfony Polyfill projektet var fött.

Symfony Polyfill och dess funktioner

Detta projekt backporterar funktioner som finns i den senaste PHP-versioner och tillhandahåller kompatibilitetslager för vissa tillägg och funktioner. Den är avsedd att användas när portabilitet mellan PHP-versioner och förlängningar är önskvärt.

Detta är en ren beskrivning av Symfony Polyfill men vad betyder det?

På grund av den snabba utvecklingen PHP språk och ISP:ernas långsamma anpassning av programvaran har de flesta utvecklare ställts inför ett enkelt val:

• Som utvecklare skapar jag applikationer i en äldre version av PHP och inte kan använda de senaste funktionerna i språket, eller
• Som utvecklare skapar jag en modern applikation med hjälp av den senaste versionen av PHP.

Men de måste också vara kompatibla med andra verktyg och tjänster som redan används både på kod och infrastruktursidan - nästan alltid med hjälp av äldre versioner av PHPBehöver jag, kära läsare, nämna den så kallade "kulfaktorn" i dessa två lösningar?

För att underlätta för utvecklare skapade Open Source-communityn under 2015 den första stabila versionen av Polyfill numrerad 1.0. Utvecklarnas liv blev enklare och man kan säga att Symfony Polyfill löste en mängd problem som t.ex. kodportabilitet mellan olika plattformar, PHP-version skillnader och gjorde det mycket enklare att refaktorisera applikationer och minska teknikskulden.

Tyvärr är det inte alla problem som kan lösas med ett enda verktyg.

Problem med att upprätthålla flera versioner av miljön

För komplexa IT-projektDet är vanligt att man måste underhålla olika versioner av miljöer för olika kunder/avdelningar. Detta resulterar i behovet av att utveckla många olika grenar av applikationer samtidigt, ofta med olika funktionella krav och med sin egen dragkraft. Jag har många gånger mött problemet med att upprätthålla samma applikation för olika kunder på olika PHP5 / PHP7-miljöer och mängden problem relaterade till bibliotekens inkompatibilitet eller deras beroenden för olika versioner är helt enkelt olösliga med endast Symfony Polyfill.

Kompetensgapet mellan medlemmarna i utvecklingsteamet

På grund av den snabba ökningen av funktioner som byggs in i PHPMånga utvecklare har inte hängt med i förändringstakten. Många av de funktioner som erbjuds i högre versioner av PHP är lätta att åstadkomma med externa bibliotek, eller så behövde utvecklarna helt enkelt inte de nya funktionerna, t.ex. PHP-fibrer. När du väljer Team är det en god idé att se till att kompetensen matchas eller att kodleveransprocessen görs mer konsekvent med hjälp av verktyg för statisk analys och tidig upptäckt av fel i versionsregressionen.

Motvilja mot förändring

Antagandet av nya språkfunktioner är fortfarande ganska lågt och PHP 5:s över 24%-andel visar tydligt att En fjärdedel av PHP-projekten kör versioner lägre än 7.x, vars säkerhetsstöd kommer att avslutas den 6 december 2022. Det innebär att när det här inlägget skrivs kommer över 25% av PHP-baserade webbprojekt att vara potentiellt sårbara för alla nya säkerhetsproblem i slutet av året. "Om det fungerar, varför ska vi bry oss"?

Slutsats

Vi bör anpassa oss till språkförändringar så snabbt som möjligt och använda de senaste lösningarna så snart som möjligt. Under en eventuell migrering av ett Legacy-projekt är det värt att inkludera Symfony Polyfill som en hjälp och använda tekniker som Strangler Pattern och den för närvarande moderna BDD-metodiken som är fantastiskt enkel att tillämpa på Symfony-ramverk. Så är vi verkligen tvungna att använda Symfony Polyfill?

Läs mer om detta:

PHP Utveckling: 5 saker du bör veta

7 startup- och scaleup-företag som kommer att skaka om marknadsplatsen 2022

PHP utveckling. Symfony konsolkomponent - tips och tricks