Projekta uzturēšana PHP: 5 kļūdas, no kurām jāizvairās

PHPtāpat kā citām valodām ir daži trūkumi, kas nav nekā vērti, ja runa ir par pārvaldības IT projekts kur PHP ir vadošā valoda.

Zemāk esam apkopojuši šo problēmu sarakstu, kā arī padomus, kā no tām izvairīties.

1. PHP standartu ieteikumu neievērošana

PHP tiek uzskatīta par "vieglu valodu", jo tai ir ļoti zema piekļuves barjera. Tas rada lielas atšķirības kodēšanas standartos un to, kā globālās saskarnes tiek īstenotas dažādās ārējās bibliotēkās. Lai ieviestu kārtību, tika ieviests standartu kopums. Tie apraksta veidu kopumu, kā izstrādātājs īstenošana var atbilst jebkuram standartā noteiktajam ierobežojumu kopumam. Vienkāršs piemērs Notikumu dispečers:

Klausītājs - klausītājs ir jebkurš PHP izsaucamais, kas sagaida, ka tam tiks nodots notikums. Vienam un tam pašam Notikumam var nodot nulli vai vairākus klausītājus. Klausītājs VAR uzdot kādu citu asinhronu darbību, ja tas tā izvēlas.

Izmantojot šo standartu, ikviens izstrādātājs, kas izmanto PSR komponentu nomenklatūru, var ne tikai viegli sazināties ar kods ar citiem izstrādātājiem.
Šo standartu ieviešana praksē, piemēram, izmantojot PHP Pareizais veids vadlīnijas un bibliotēkas, kas atbalsta globālās PSR saskarnes, ļauj PHP izstrādātāji ātrāk pielāgoties funkcionālo, arhitektūras un infrastruktūras prasību izmaiņām.

Kā no tā izvairīties?

Kā kodubāzes uzturētājs vienmēr atcerieties izmantot pārbaudītas un stabilas ārējo bibliotēku versijas, un, ja esat spiests izmantot pielāgotu risinājumu, ievietojiet to, izmantojot PHP PSR.
Visu pieejamo standartu saraksts ir pieejams galvenajā tīmekļa vietnē. PHP-FIG. Paplašinātie standarti ar praktiskiem aprakstiem ir pieejami dažādos formātos no PHP Pareizais veids mājas lapa.
Labākās bibliotēkas, kas atbilst PHP-FIG standartiem, ir uzskaitītas vietnē PHP līga tīmekļa vietne.

2. Kompozitora.json atkarību versiju nefiksēšana

Projektos, kas izmanto atkarību pārvaldnieku Komponists bieži vien ir situācija, kad pēc ilgāka atbalsta un uzturēšanas perioda produkts ražošanas vidē ir nepieciešams ieviest funkcionālās izmaiņas, nepārbūvējot visu arhitektūru. Visbiežāk projektu pēc tam pārņem programmētājs, kura uzdevums ir palaist lokālo izstrādes vidi un sākt darbu ar biļetēm. Pamatojoties uz composer.lock failu, izstrādātājs var atjaunot projektu tādā stāvoklī, kādā tas bija ražošanas vidē, bet jebkuras izmaiņas, kas tiek veiktas composer.json failu, piemēram, pievienojot bibliotēku, radīs kļūdu kaskādi, kas palielinās faktisko laiku, kas vajadzīgs, lai ieviestu jaunu bibliotēku. komanda dalībnieks organizācijai, kā arī risinājuma izstrādes laiks.

Kā no tā izvairīties?

Kad lietojumprogramma ir stabila, koda uzturētājam ir jāfiksē bibliotēku versijas, kas atrodas composer.json failu un izveidot skaidru procedūru, kurā aprakstīts, kā atjaunināt to versijas, ja tas būs nepieciešams nākotnē.

Apsveriet arī iespēju izmantot mehānismu, kas pārbaudītu izmantoto bibliotēku drošības statusu un automatizētu drošības atjauninājumu nodrošināšanas procesu.
Izmantojot bezmaksas rīkus, piemēram. Dependabot, mēs varam gan uzturēt konsekventu, pārvaldāmu atkarīgo bibliotēku versiju infrastruktūru, gan nodrošināt drošības garantijas mūsu lietojumprogrammai.

3. Nepietiekama prasību apkopošana

> Tas ir tikai CRUD, kāpēc gan to darīt?

> Ir bibliotēka, kas tieši to dara!

In the PHP jomā, īstenojot produkta biznesa loģiku, ir viegli nonākt aizmāršības virpulī. Gadu gaitā ir bijuši simtiem projektu, kuros [izveidoti administratīvie paneļi, lai pārvaldītu dati modeļus](https://backpackforlaravel.com/), [ģenerēt Google Analytics līdzīgus skatus](https://github.com/Kunstmaan/KunstmaanDashboardBundle) vai [atrisināt PHP async problēmas](https://laravel.com/docs/9.x/octane) ar burvju nūjiņas pieskārienu (labi, ar vienu komandrindas vaicājumu).
PHP pasaule ir pilna ar gatavām implementācijām, kas darbojas 99,9% gadījumu.
0.1% ir vieta, kur biznesa loģika saduras ar izmantoto bibliotēku funkcionālajiem ierobežojumiem.
Projekta beigās visgrūtāk ir īstenot tieši šos tā sauktos "papildu risinājumus".

Kā no tā izvairīties?

Nav iespējams atrast zelta vidusceļu starp pārinženierijas un nepietiekamas inženierijas līmeni, ja nav pienācīgas izpratnes par produkta biznesa jomu.
Uzsākot izstrādes komanda dalībniekiem jau produkta izstrādes posmā un proaktīvi sadarbojoties ar produkta īpašnieku, jūs varat samazināt problēmas risku, ka tiks izmantots risinājums, kas nedarbosies kā ilgtermiņa ieguldījums.

4. Izmaksu samazināšana, izvairoties no testu rakstīšanas

PHP noteikti nav ideāls. Tās trūkumi attiecībā uz statisko tipizēšanu, ģenerikas atbalsta trūkumu un arhaisko metožu pastāvīgu atbalstu joprojām ir jokiem jocīgu jautājumu avots programmētāju vidū. Tomēr jau kādu laiku PHP izstrādātāji ir pieejami arvien jaudīgāki rīki, piemēram. PHPStan, Xdebug, PHP-CS-Fixer kas ļauj saglabāt konsekvenci un statisko tipizēšanu, tādējādi izvairoties no daudzām kļūdām. Tomēr pārāk maz uzmanības tiek pievērsts testiem, un, ja tie ir pareizi īstenoti, tie ātri atmaksājas investīciju veidā.
- regresijas kļūdu samazināšana
- lielāka informētība par produktu iespējām.
- palielināt izstrādātāja piederības sajūtu kodam.

Kā no tā izvairīties?

Nesamaziniet izmaksas testēšanai. Vienkāršu Behat skriptu rakstīšana patiešām nav tik sarežģīta, jums nav uzreiz jāraksta sarežģīti end-to-end testi vai jāiedziļinās implementācijas detaļās un jātestē katra metode.
Vienkāršs Behat tests, kas aprakstīts dabiskā domēna valodā, bieži vien ir vērtīgāks par visrūpīgāk uzrakstītu "no gala līdz galam" testu.

5. Modernās arhitektūras modeļu neņemšana vērā

Portāls PHP valoda un tās divi jaudīgākie ietvari Laravel un Symfony ir pilnībā piemērotas modernas, funkcionālas un, pats galvenais, augstas veiktspējas arhitektūras izveidei. Dažādu ziņojumu rindu sistēmu atbalsts un arvien ātrāka PHP veiktspējas uzlabojumi no versijas uz versiju ļauj mums viegli izveidot mikroservisi pamatojoties uz mikrokādēm. Tomēr lielākoties mēs joprojām paļaujamies uz monolītām sistēmām. Tas nav nekas slikts, taču, apsverot šādu sistēmu izstrādi, mums jāpievērš liela uzmanība domēna robežām un jānosaka saskarnes punkts starp jaunajiem risinājumiem un vecākajām sistēmas daļām.

Kā no tā izvairīties?

Izstrādājot jebkuru PHP tīmekļa vietni, ir vērts rūpīgi izpētīt pašreizējos risinājumus, izveidot globālas saskarnes datu saziņai un ieviest jaunas funkcijas, izmantojot jaunākās metodes un praksi. Viens no populārākajiem praksē izmantotajiem risinājumiem ir Dusinātājs modelis.