Kodėl mums reikia "Symfony Polyfill" (... ir kodėl neturėtume)

Daugumoje šiuolaikinių PHP projektai, pastebėsite, kad yra didelė priklausomybė nuo "Symfony Polyfill biblioteka. Šiame straipsnyje paaiškinsime ne tik tai, kaip ji veikia ir kaip ji susijusi su "Symfony" projektai, tačiau taip pat gilinsimės į problemos, kurią bandoma išspręsti, idėją.

Šiek tiek istorijos

PHP ilgą laiką buvo prastos būklės. Tai buvo 2005 m., kai Andrejus Zmievskis pradėjo projektas įdiegti gimtąją "Unicode" palaikymo funkciją PHP dėl mišrių atsiliepimų ir daugelio susirūpinimą keliančių priežasčių, kad PHP eina netinkama linkme. Vystymasis PHP 6.x pradėtas. Tačiau jis taip ir nebuvo baigtas - tai jau kitos dienos istorija. Po 10 metų, kažkur 2014-2015 m., Dmitrijus Stogovas, Xinchen Hui ir Nikita Popovas pradėjo phpng - projektas, kuriuo optimizuotas ir pertvarkytas vidinis "Zend Engine", naudojamas PHP.

>_ Gimė PHP 7

Ir pastaraisiais metais, PHP auga sparčiau nei bet kada anksčiau, šiuo metu yra stabili 8.1 versija.

Dėl spartaus naujų kalbos funkcijų plėtojimo prie šių pokyčių turėjo prisitaikyti ne tik kūrėjai, bet ir infrastruktūros bei prieglobos paslaugų teikėjai.

Siekdami užtikrinti, kad mes, programuotojai, galėtume naudotis naujausiomis ir geriausiomis mūsų mylimos programavimo kalbos funkcijomis. "Symfony Polyfill gimė projektas.

"Symfony Polyfill" ir jo funkcija

Šis projektas palaiko naujausioje PHP versijos ir suteikia suderinamumo sluoksnius kai kuriems plėtiniams ir funkcijoms. Jis skirtas naudoti, kai perkeliamumas tarp PHP versijos ir plėtinius.

Tai grynas aprašymas "Symfony Polyfill bet ką tai reiškia?

Dėl sparčiai besikeičiančių PHP kalba ir interneto paslaugų teikėjų programinės įrangos pritaikymo ne pagal poreikius, dauguma kūrėjų susidūrė su paprastu pasirinkimu:

• Kaip kūrėjas, kuriu programas senesnėje versijoje PHP ir negali naudotis naujausiomis kalbos funkcijomis, arba
• Kaip programuotojas kuriu modernią programą naudodamas naujausią versiją PHP.

Tačiau jie turėjo išlaikyti suderinamumą su kitais įrankiais ir paslaugomis, jau naudojamais tiek kodas ir infrastruktūros pusėje - beveik visada naudojamos senesnės versijos PHP.Ar reikia, mielas skaitytojau, minėti šių dviejų sprendimų vadinamąjį ‘linksmumo faktorių’?

Siekdama palengvinti kūrėjams kelią, 2015 m. atvirojo kodo bendruomenė sukūrė pirmoji stabili "Polyfill" versija, pažymėta numeriu 1.0. Programuotojų gyvenimas tapo lengvesnis ir galima sakyti, kad ’Symfony Polyfill" išsprendė daugybę problemų, tokių kaip kodo perkeliamumas tarp skirtingų platformų, PHP versija skirtumus, taip pat palengvino programų pertvarkymą ir sumažino technologinę skolą.

Deja, ne visas problemas galima išspręsti vienu įrankiu.

Problemos, susijusios su kelių aplinkos versijų palaikymu

Sudėtingų IT projektai, skirtingų aplinkų versijų palaikymas skirtingiems klientams, skyriams ir padaliniams yra įprasta procedūra. Dėl to vienu metu tenka kurti daug skirtingų šakų taikomųjų programų, kurioms dažnai keliami skirtingi funkciniai reikalavimai ir kurios turi savo trauką. Ne kartą susidūriau su tos pačios programos palaikymo skirtingiems klientams skirtingose PHP5 / PHP7 aplinkose problema, o daugybė problemų, susijusių su bibliotekų ar jų priklausomybių nesuderinamumu skirtingoms versijoms, yra tiesiog neišsprendžiamos naudojant tik "Symfony Polyfill.

Kvalifikacijos atotrūkis tarp vystymosi team narių

Dėl spartaus funkcijų, integruotų į PHP, daugelis kūrėjų neatsiliko nuo pokyčių tempo. Daugelis funkcijų, siūlomų aukštesnėse versijose PHP lengva pasiekti naudojant išorines bibliotekas, arba kūrėjams paprasčiausiai nereikėjo naujų funkcijų, pvz. PHP skaidulos. Pasirinkę komanda nariams, pravartu įsitikinti, kad įgūdžiai yra suderinti arba kad kodo pristatymo procesas būtų nuoseklesnis, naudojant statinės analizės įrankius ir anksti nustatant versijų regresijos klaidas.

Nenoras keistis

Naujų kalbos funkcijų diegimas vis dar yra gana menkas ir PHP 5 daugiau nei 24% dalis aiškiai rodo, kad ketvirtadalyje PHP projektų naudojamos žemesnės nei 7.x versijos., kurios saugumo parama bus nutraukta 2022 m. gruodžio 6 d. Tai reiškia, kad šio pranešimo rašymo metu daugiau nei 25% PHP pagrindu veikiančių Tinklalapis iki metų pabaigos projektai bus potencialiai pažeidžiami dėl visų naujų saugumo spragų. “Jei tai veikia, kodėl turėtume vargintis”?

Išvada

Turėtume kuo greičiau prisitaikyti prie kalbos pokyčių ir kuo greičiau naudoti naujausius sprendimus. Per galimą palikimo projekto perkėlimą verta įtraukti "Symfony Polyfill kaip pagalbinė priemonė ir naudojant tokius metodus kaip Strangler Pattern ir šiuo metu madingą BDD metodiką, kurią pasakiškai lengva pritaikyti "Symfony" sistema. Taigi, ar tikrai esame priversti naudoti "Symfony Polyfill?

Skaityti daugiau:

PHP Kūrimas: 5 dalykai, kuriuos turėtumėte žinoti

7 startuoliai ir mastelio įmonės, kurios 2022 m. sudrebins rinką

PHP Kūrimas. "Symfony" konsolės komponentas - Patarimai ir gudrybės