Projekto palaikymas PHP: 5 klaidos, kurių reikia vengti

PHPkaip ir kitos kalbos, turi tam tikrų trūkumų, kurie yra beverčiai, kai reikia valdyti IT projektas kur PHP yra pagrindinė kalba.

Toliau pateikiame jų sąrašą ir patarimus, kaip jų išvengti.

1. Nesilaikoma PHP standartų rekomendacijų

PHP laikoma "lengva kalba", nes į ją patekti yra labai mažas barjeras. Dėl to labai skiriasi kodavimo standartai ir tai, kaip globalios sąsajos įgyvendinamos įvairiose išorinėse bibliotekose. Siekiant įvesti tvarką, buvo įvestas standartų rinkinys. Juose aprašomi būdai, kaip kūrėjas įgyvendinimas gali atitikti bet kurį standarte reikalaujamų apribojimų rinkinį. Paprastas pavyzdys Įvykių dispečeris:

Klausytojas - Klausytojas yra bet kuris PHP callable, kuriam tikimasi perduoti įvykį. Tas pats Įvykis gali būti perduotas nuliui ar daugiau klausytojų. Klausytojas GALI nurodyti kokį nors kitą asinchroninį elgesį, jei jis to nori.

Naudodamasis šiuo standartu kiekvienas PSR-komponentų nomenklatūrą naudojantis kūrėjas gali ne tik lengvai bendrauti, bet ir kodas su kitais kūrėjais.
Šių standartų taikymas praktikoje, pvz. PHP Tinkamas būdas gairės ir bibliotekos, palaikančios visuotines PSR sąsajas, leidžia PHP kūrėjai greičiau prisitaikyti prie funkcinių, architektūrinių ir infrastruktūros reikalavimų pokyčių.

Kaip to išvengti?

Būdami kodų bazės prižiūrėtojais, visada nepamirškite naudoti patikrintas ir stabilias išorinių bibliotekų versijas, o jei esate priversti naudoti pasirinktinį sprendimą, įgyvendinkite jį naudodami PHP PSR.
Visų prieinamų standartų sąrašą galima rasti pagrindinėje svetainėje. PHP-FIG. Išplėstinius standartus su praktiniais aprašymais galima rasti įvairiais formatais iš PHP Tinkamas būdas namų puslapis.
Geriausios bibliotekos, atitinkančios PHP-FIG standartus, išvardytos PHP lyga interneto svetainėje.

2. Kompozitoriaus.json priklausomybių versijų neužrakinimas

Projektuose, kuriuose naudojama priklausomybių tvarkyklė Kompozitorius dažnai pasitaiko situacija, kai po ilgo paramos ir priežiūros laikotarpio produktas gamybinėje aplinkoje reikia įgyvendinti funkcinius pakeitimus nepertvarkant visos architektūros. Dažniausiai tada projektą perima programuotojas, kurio užduotis - paleisti vietinę kūrimo aplinką ir pradėti dirbti su bilietais. Remdamasis composer.lock failą, kūrėjas gali atkurti projekto būklę, kokia ji buvo gamybinėje aplinkoje, tačiau bet kokie pakeitimai composer.json failą, pvz., pridedant biblioteką, sukels kaskadą klaidų, dėl kurių pailgės faktinis naujo failo įgyvendinimo laikas. komanda organizacijos nariui, taip pat sprendimo kūrimo laiką.

Kaip to išvengti?

Kai programa bus stabili, kodo prižiūrėtojas turėtų užrakinti bibliotekų versijas composer.json failą ir sukurti aiškią procedūrą, kurioje būtų aprašyta, kaip atnaujinti jų versijas, jei to prireiktų ateityje.

Taip pat apsvarstykite galimybę įdiegti mechanizmą, kuris leistų patikrinti naudojamų bibliotekų saugumo būklę ir automatizuoti saugumo atnaujinimų teikimo procesą.
Naudodami nemokamus įrankius, pvz. Dependabot, galime išlaikyti nuoseklią, valdomą priklausomų bibliotekų versijų infrastruktūrą ir užtikrinti savo programos saugumą.

3. Prastas reikalavimų rinkimas

> Tai tik CRUD, kam vargintis?

> Yra biblioteka, kuri būtent tai ir daro!

Į PHP sritį, įgyvendinant produkto verslo logiką lengva pakliūti į užmaršumo sūkurį. Per daugelį metų buvo šimtai projektų, kuriuose [sukurti administraciniai skydeliai, skirti valdyti duomenys modeliai](https://backpackforlaravel.com/), [sukurti į "Google Analytics" panašius vaizdus](https://github.com/Kunstmaan/KunstmaanDashboardBundle) arba [išspręsti PHP asinchronizacijos problemas](https://laravel.com/docs/9.x/octane) vienu burtų lazdelės paspaudimu (gerai, viena komandinės eilutės užklausa).
PHP Pasaulyje gausu paruoštų realizacijų, kurios veikia 99,9% atvejų.
Tai 0.1% yra ta vieta, kur verslo logika susiduria su naudojamų bibliotekų funkciniais apribojimais.
Būtent šiuos vadinamuosius "įvadinius" elementus sunkiausia įgyvendinti projekto pabaigoje.

Kaip to išvengti?

Tinkamai nesupratus produkto verslo srities, neįmanoma rasti aukso vidurio tarp perteklinės ir nepakankamos inžinerijos.
Pradėdami kūrimo komanda nariai ankstyvuoju produkto kūrimo etapu ir aktyviai bendradarbiaudami su produkto savininku, galite iki minimumo sumažinti problemos, susijusios su sprendimu, kuris neveiks kaip ilgalaikė investicija, riziką.

4. Išlaidų mažinimas vengiant testų rašymo

PHP tikrai nėra tobulas. Jos trūkumai, susiję su statiniu tipavimu, generikų palaikymo stoka ir nuolatiniu archajiškų metodų palaikymu, vis dar kelia juoką programuotojams. Tačiau jau kurį laiką PHP kūrėjai buvo suteikta vis daugiau ir daugiau galingų priemonių, pvz. PHPStan, Xdebug, PHP-CS-Fixer kurie leidžia išlaikyti nuoseklumą ir statinį tipavimą - taip išvengiama daugelio klaidų. Vis dėlto per mažai dėmesio skiriama testams, o teisingai įgyvendinus juos, investicijos greitai atsiperka.
- regresijos klaidų mažinimas
- didesnis informuotumas apie produkto galimybes.
- didėjantis programuotojo atsakomybės už kodą jausmas.

Kaip to išvengti?

Nemažinkite išlaidų bandymams. Rašyti paprastus "Behat" scenarijus tikrai nėra sunku, nereikia iš karto rašyti sudėtingų testų "nuo galo iki galo" arba gilintis į įgyvendinimo detales ir testuoti kiekvieną metodą.
Paprastas "Behat" testas, aprašytas natūralia domeno kalba, dažnai yra vertingesnis už kruopščiausiai parašytą "nuo galo iki galo" testą.

5. Neatsižvelgiama į šiuolaikinės architektūros modelius

Svetainė PHP kalba ir dvi galingiausios jos sistemos Laravel ir Symfony yra visiškai tinkami moderniai, funkcionaliai ir, svarbiausia, didelio našumo architektūrai kurti. Įvairių pranešimų eilių sistemų palaikymas ir vis spartesnė PHP nuo versijos iki versijos gerinamas našumas. mus lengvai sukurti mikroservisai remiantis mikrokarkasais. Tačiau dažniausiai vis dar remiamės monolitinėmis sistemomis. Tame nėra nieko blogo, tačiau, svarstydami tokių sistemų kūrimą, turime atkreipti didelį dėmesį į srities ribas ir nustatyti naujų sprendimų sąsajos su senesnėmis sistemos dalimis tašką.

Kaip to išvengti?

Kuriant bet kokį PHP svetainėje, verta atidžiai peržiūrėti esamus sprendimus, sukurti visuotines duomenų perdavimo sąsajas ir įgyvendinti naujas funkcijas taikant naujausius metodus ir praktiką. Vienas populiariausių praktikoje naudojamų sprendimų yra Dusintojo modelis.