Projekti haldamine PHP-s: 5 viga, mida vältida

PHP, nagu ka teistel keeltel, on mõned puudused, mis ei ole midagi väärt, kui tegemist on haldamisega IT projekt kus PHP on juhtiv keel.

Järgnevalt oleme koostanud nende nimekirja koos nõuannetega, kuidas neid vältida.

1. PHP standardite soovituste mittejärgimine

PHP peetakse "lihtsaks keeleks", sest selles on väga madal sisenemisbarjäär. Selle tulemuseks on suured erinevused kodeerimisstandardites ja selles, kuidas globaalseid liideseid rakendatakse erinevates välistes raamatukogudes. Püüdes tuua korda, võeti kasutusele standardite kogum. Need kirjeldavad hulga viise, kuidas rakenduse arendaja saab rahuldada mis tahes standardis nõutud piiranguid. Lihtne näide Sündmuse dispetšer:

Kuulaja - Kuulaja on mis tahes PHP callable, mis ootab, et talle edastatakse Event. Sama sündmuse võib edastada nullile või mitmele kuulajale. Kuulaja VÕIB soovi korral nõuda muud asünkroonset käitumist.

Seda standardit kasutades saab iga arendaja, kes kasutab PSR-komponentide nomenklatuuri, mitte ainult hõlpsasti suhelda, vaid ka kood teiste arendajatega.
Nende standardite rakendamine praktikas, näiteks kasutades PHP Õige tee suunised ja raamatukogud, mis toetavad globaalseid PSR-liideseid, võimaldab PHP arendajad kohaneda kiiremini funktsionaalsete, arhitektuuriliste ja infrastruktuurinõuetega.

Kuidas ma saan seda vältida?

Koodibaasi hooldajana pidage alati meeles, et kasutage väliste raamatukogude tõestatud ja stabiilseid versioone ning kui olete sunnitud kasutama kohandatud lahendust, rakendage seda PHP PSR-i abil.
Kõigi kättesaadavate standardite loetelu on kättesaadav veebisaidil PHP-FIG. Laiendatud standardid koos praktiliste kirjeldustega on saadaval erinevates formaatides alates PHP Õige tee kodulehekülg.
Parimad raamatukogud, mis vastavad PHP-FIG standarditele, on loetletud aadressil PHP Liiga veebisait.

2. Composer.json sõltuvuste versioonide lukustamata jätmine

Projektides, mis kasutavad sõltuvuse haldurit Helilooja sageli tekib olukord, kus pärast pikka aega kestnud toetamist ja hooldamist on toode tootmiskeskkonnas on vaja rakendada funktsionaalseid muudatusi ilma kogu arhitektuuri ümber ehitamata. Enamasti võtab projekti seejärel üle programmeerija, kelle ülesanne on käivitada kohalik arenduskeskkond ja alustada tööd piletite kallal. Tuginedes composer.lock faili, on arendajal võimalik taastada projekt sellisesse olekusse, milles see oli tootmiskeskkonnas, kuid iga muudatus faili composer.json faili, näiteks raamatukogu lisamisega, põhjustab vigade kaskaadi, mis suurendab uue rakenduse tegelikku aega. meeskond liige organisatsioonile, samuti lahenduse väljatöötamise aeg.

Kuidas ma saan seda vältida?

Kui rakendus on stabiilne, peaks koodi hooldaja lukustama raamatukogude versioonid raamatukogude composer.json faili ja luua selge kord, mis kirjeldab, kuidas nende versioone vajaduse korral tulevikus uuendada.

Kaaluge ka mehhanismi käivitamist kasutatud raamatukogude turvastatuse kontrollimiseks ja turvavärskenduste pakkumise automatiseerimiseks.
Kasutades selliseid tasuta vahendeid nagu Dependabotsaame nii säilitada järjepidevat, hallatavat versioonimisinfrastruktuuri sõltuvate raamatukogude jaoks kui ka tagada meie rakenduse turvalisuse.

3. Kehv nõuete kogumine

> See on lihtsalt CRUD, milleks vaeva näha?

> On olemas raamatukogu, mis teeb täpselt seda!

In the PHP domeeni puhul on lihtne sattuda toote äriloogika rakendamisel unustuse keerisesse. Aastate jooksul on olnud sadu projekte, mis [loovad andmemudelite halduspaneele](https://backpackforlaravel.com/), [genereerivad Google Analyticsi sarnaseid vaateid](https://github.com/Kunstmaan/KunstmaanDashboardBundle) või [lahendavad PHP asünkroonseid probleeme](https://laravel.com/docs/9.x/octane) võlukeppega (OK, ühe käsurea päringuga).
PHP maailm on täis valmis rakendusi, mis töötavad 99,9% korda.
See 0.1% on koht, kus äriloogika põrkub kasutatud raamatukogude funktsionaalsete piirangutega.
Just neid nn " sisseviskeid" on projekti lõpus kõige raskem rakendada.

Kuidas ma saan seda vältida?

Ei ole mingit võimalust leida kuldset keskteed üle- ja alatehnika vahel ilma toote ärivaldkonna nõuetekohase mõistmiseta.
Alustades arendusmeeskond liikmed varakult toote faasis ja ennetavalt, töötades koos tooteomanikuga, saate minimeerida probleemi riski, et kasutate lahendust, mis ei toimi pikaajalise investeeringuna.

4. Kulude vähendamine testide kirjutamise vältimise teel

PHP ei ole täiuslik, see on kindel. Selle puudused staatilise tüübistamise, geneeriliste meetodite toetuse puudumise ja arhailiste meetodite jätkuva toetamise osas on programmeerijate seas ikka veel nalja allikaks. Siiski, mõnda aega PHP arendajad on antud üha võimsamaid vahendeid, nagu PHPStan, Xdebug, PHP-CS-Fixer mis võimaldavad neil säilitada järjepidevust ja staatilist tüübistamist - seega välditakse paljusid vigu. Siiski pööratakse liiga vähe tähelepanu testidele ja need, kui need on õigesti rakendatud, toovad kiire tulu investeeringu näol.
- regressioonivigade vähendamine
- suurem teadlikkus toote võimalustest
- arendajate kooditunde suurendamine

Kuidas ma saan seda vältida?

Ärge vähendage testimise kulusid. Lihtsate Behat-skriptide kirjutamine ei ole tegelikult nii raske, te ei pea kohe kirjutama keerulisi otsast lõpuni teste või laskuma rakendamise üksikasjadesse ja testima iga meetodit.
Loomulikus domeenikeeles kirjeldatud lihtne Behat-test on sageli rohkem väärt kui kõige hoolikamalt kirjutatud otsast lõpuni test.

5. Kaasaegsete arhitektuurimustrite mittearvestamine

The PHP keel ja selle kaks kõige võimsamat raamistikku Laravel ja Symfony sobivad täielikult kaasaegse, funktsionaalse ja eelkõige suure jõudlusega arhitektuuri loomiseks. Erinevate sõnumijärjekorra süsteemide toetus ja üha kiirem PHP jõudluse paranemine versioonist versioonini võimaldab meil hõlpsasti luua mikroteenuseid, mis põhinevad mikroraamistikel. Enamasti toetume siiski endiselt monoliitse süsteemidele. Selles ei ole midagi halba, kuid selliste süsteemide arendamist kaaludes peame pöörama suurt tähelepanu domeeni piiridele ja määrama kindlaks, kus on uute lahenduste ja süsteemi vanemate osade vaheline liidesepunkt.

Kuidas ma saan seda vältida?

Kui arendatakse mis tahes PHP veebisaidi, tasub tähelepanelikult uurida praeguseid lahendusi, luua globaalsed liidesed andmeside jaoks ning rakendada uusi funktsioone, kasutades uusimaid tehnikaid ja tavasid. Üks populaarsemaid praktikas kasutatavaid lahendusi on Strangleri muster.