Projektin ylläpito PHP:ssä: 5 virhettä, joita kannattaa välttää

PHP, kuten muillakin kielillä, on joitakin haittoja, jotka eivät ole minkään arvoisia, kun on kyse hallinta IT projekti jossa PHP on johtava kieli.

Olemme koonneet alla olevan luettelon niistä ja antaneet vinkkejä niiden välttämiseksi.

1. PHP-standardien suositusten noudattamatta jättäminen

PHP pidetään "helppona kielenä", koska sen käyttöönoton kynnys on hyvin matala. Tämän seurauksena koodausstandardeissa ja siinä, miten globaalit rajapinnat on toteutettu eri ulkoisissa kirjastoissa, on suuria eroja. Järjestyksen aikaansaamiseksi otettiin käyttöön joukko standardeja. Niissä kuvataan joukko tapoja, joilla toteutuksen kehittäjä voi täyttää kaikki standardin vaatimat rajoitukset. Yksinkertainen esimerkki Tapahtuman lähettäjä:

Kuuntelija - Kuuntelija on mikä tahansa PHP callable, joka odottaa, että sille välitetään Event. Sama tapahtuma voidaan välittää nollalle tai useammalle kuuntelijalle. Kuuntelija VOI halutessaan antaa jonkun muun asynkronisen käyttäytymisen.

Tätä standardia käyttämällä jokainen PSR-ehdokasnimikkeistöä käyttävä kehittäjä voi helposti paitsi kommunikoida myös koodi muiden kehittäjien kanssa.
Näiden standardien toteuttaminen käytännössä, esimerkiksi hyödyntämällä PHP Oikea tapa ohjeet ja kirjastot, jotka tukevat globaaleja PSR-liitäntöjä, mahdollistavat sen, että PHP-kehittäjät sopeutua nopeammin toiminnallisten, arkkitehtuuristen ja infrastruktuurivaatimusten muutoksiin.

Miten voin välttää sen?

Koodipohjan ylläpitäjänä muista aina käyttää ulkoisten kirjastojen testattuja ja vakaita versioita, ja jos sinun on pakko käyttää mukautettua ratkaisua, toteuta se käyttämällä PHP PSR:ää.
Luettelo kaikista saatavilla olevista standardeista on saatavissa verkkosivuilta. PHP-FIG. Laajennetut standardit ja käytännön kuvaukset ovat saatavilla eri muodoissa osoitteesta PHP Oikea tapa kotisivut.
Parhaat PHP-FIG-standardien mukaiset kirjastot on lueteltu osoitteessa PHP-liiga verkkosivusto.

2. composer.json-riippuvuusversioiden lukitsematta jättäminen

Projekteissa, jotka käyttävät riippuvuuksien hallintaa Säveltäjä on usein tilanne, jossa pitkän tuki- ja ylläpitovaiheen jälkeen, kun tuote tuotantoympäristössä on tarpeen toteuttaa toiminnallisia muutoksia rakentamatta koko arkkitehtuuria uudelleen. Useimmiten projekti siirtyy tällöin ohjelmoijan vastuulle, jonka tehtävänä on käynnistää paikallinen kehitysympäristö ja aloittaa lippujen työstäminen. Perustuen composer.lock tiedosto, kehittäjä voi palauttaa projektin siihen tilaan, jossa se oli tuotantoympäristössä, mutta kaikki muutokset tiedostoon composer.json tiedosto, esim. lisäämällä kirjasto, aiheuttaa virheiden kaskadin, joka lisää todellista toteutusaikaa uuden joukkue jäsenelle organisaatiolle sekä ratkaisun kehittämisaika.

Miten voin välttää sen?

Kun sovellus on vakaa, koodin ylläpitäjän tulisi lukita kirjastojen versiot kirjastoon composer.json tiedosto ja luoda selkeä menettely, jossa kuvataan, miten niiden versiot päivitetään tarvittaessa tulevaisuudessa.

Harkitse myös mekanismin käyttöönottoa käytettyjen kirjastojen tietoturvatilanteen tarkistamiseksi ja tietoturvapäivitysten toimittamisen automatisoimiseksi.
Käyttämällä ilmaisia työkaluja, kuten Dependabotvoimme sekä ylläpitää johdonmukaista ja hallittavaa versiointi-infrastruktuuria riippuvaisille kirjastoille että antaa sovelluksellemme turvatakuun.

3. Huono vaatimusten kerääminen

> Se on vain CRUD, miksi vaivautua?

> On olemassa kirjasto, joka tekee juuri niin!

Vuonna PHP toimialueella on helppo joutua unohduksen pyörteisiin, kun toteutetaan tuotteen liiketoimintalogiikkaa. Vuosien varrella on toteutettu satoja projekteja, joissa [luodaan hallinnollisia paneeleja tietomallien hallintaan](https://backpackforlaravel.com/), [luodaan Google Analyticsin kaltaisia näkymiä](https://github.com/Kunstmaan/KunstmaanDashboardBundle) tai [ratkaistaan PHP:n asynkroniset ongelmat](https://laravel.com/docs/9.x/octane) taikasauvan (OK, yhden komentorivikyselyn) avulla.
PHP-maailma on täynnä valmiita toteutuksia, jotka toimivat 99,9% kertaa.
Tämä 0.1% on kohta, jossa liiketoimintalogiikka törmää käytettyjen kirjastojen toiminnallisiin rajoituksiin.
Juuri nämä niin sanotut "sisäänheitot" ovat hankalimpia toteuttaa projektin lopussa.

Miten voin välttää sen?

Kultaista keskitietä ylisuunnittelun ja alikehittämisen välillä ei ole mahdollista löytää, jos tuotteen liiketoiminta-aluetta ei ymmärretä kunnolla.
Aloittamalla kehitystiimi jäseniä jo varhaisessa tuotevaiheessa ja toimimalla ennakoivasti yhteistyössä tuotteen omistajan kanssa voit minimoida riskin ongelmasta käyttää ratkaisua, joka ei toimi pitkän aikavälin investointina.

4. Kustannusten vähentäminen välttämällä testien kirjoittamista

PHP ei ole täydellinen, se on varmaa. Sen puutteet staattisessa tyypityksessä, geneerisen tuen puuttuminen ja arkaaisten metodien jatkuva tuki ovat yhä vitsien aiheena ohjelmoijien keskuudessa. Kuitenkin jo jonkin aikaa PHP-kehittäjät on annettu yhä tehokkaampia välineitä, kuten PHPStan, Xdebug, PHP-CS-Fixer joiden avulla ne voivat säilyttää johdonmukaisuuden ja staattisen tyypityksen - ja siten välttää monia virheitä. Silti testeihin kiinnitetään liian vähän huomiota, ja kun ne toteutetaan oikein, ne tuottavat nopean tuoton investoinnille, joka on muodossa
- regressiovirheiden vähentäminen
- lisääntynyt tietoisuus tuotteiden ominaisuuksista
- Kehittäjien koodin omistajuuden tunteen lisääminen

Miten voin välttää sen?

Älä leikkaa testauksesta aiheutuvia kustannuksia. Yksinkertaisten Behat-skriptien kirjoittaminen ei todellakaan ole kovin vaikeaa, sinun ei tarvitse kirjoittaa heti monimutkaisia end-to-end-testejä tai mennä toteutuksen yksityiskohtiin ja testata jokaista menetelmää.
Yksinkertainen Behat-testi, joka on kuvattu luonnollisella toimialueen kielellä, on usein arvokkaampi kuin kaikkein tarkoin kirjoitettu lopputesti.

5. Nykyaikaisia arkkitehtuurimalleja ei oteta huomioon

The PHP-kieli ja sen kaksi tehokkainta kehystä Laravel ja Symfony soveltuvat täysin modernin, toimivan ja ennen kaikkea suorituskykyisen arkkitehtuurin luomiseen. Tuki erilaisille viestijonojärjestelmille ja yhä nopeammat PHP suorituskykyparannukset versiosta toiseen mahdollistavat sen, että voimme helposti luoda mikropalveluita, jotka perustuvat mikrokehyksiin. Suurimmaksi osaksi luotamme kuitenkin edelleen monoliittisiin järjestelmiin. Siinä ei ole mitään väärää, mutta harkitessamme tällaisten järjestelmien kehittämistä meidän on kiinnitettävä tarkkaa huomiota toimialueen rajoihin ja määritettävä rajapintakohta uusien ratkaisujen ja järjestelmän vanhempien osien välillä.

Miten voin välttää sen?

Kehitettäessä mitä tahansa PHP verkkosivujen avulla kannattaa tarkastella tarkkaan nykyisiä ratkaisuja, luoda maailmanlaajuisia rajapintoja tiedonsiirtoa varten ja toteuttaa uusia toimintoja uusimpia tekniikoita ja käytäntöjä käyttäen. Yksi suosituimmista käytännössä käytetyistä ratkaisuista on Kuristajan kuvio.