Vedlikehold av et prosjekt i PHP: 5 feil du bør unngå

PHPhar, i likhet med andre språk, noen ulemper som ikke er verdt noe når det gjelder å administrere et IT prosjekt hvor PHP er det ledende språket.

Nedenfor har vi samlet en liste over disse, sammen med tips til hvordan du kan unngå dem.

1. Følger ikke anbefalingene i PHP-standarden

PHP regnes som et "enkelt språk" fordi det har en svært lav inngangsbarriere. Dette resulterer i store forskjeller i kodestandarder og hvordan globale grensesnitt implementeres i ulike eksterne biblioteker. I et forsøk på å skape orden ble det innført et sett med standarder. Disse beskriver et sett med måter utvikleren av implementasjonen kan tilfredsstille et hvilket som helst sett med begrensninger som kreves av standarden. Et enkelt eksempel for Event Dispatcher:

Lytter - En lytter er en hvilken som helst PHP som forventer å få overlevert en hendelse. Null eller flere lyttere kan få overført den samme hendelsen. En lytter KAN sette en annen asynkron oppførsel i kø hvis den selv ønsker det.

Ved hjelp av denne standarden kan alle utviklere som bruker PSR-kompatibel nomenklatur enkelt ikke bare kommunisere med, men også kode med andre utviklere.
Å omsette disse standardene i praksis, for eksempel ved å bruke PHP Den riktige måten retningslinjer og biblioteker som støtter globale PSR-grensesnitt, gjør det mulig PHP-utviklere for å tilpasse seg raskere til endringer i funksjonelle, arkitektoniske og infrastrukturelle krav.

Hvordan kan jeg unngå det?

Som vedlikeholder av kodebasen må du alltid huske å bruke utprøvde og stabile versjoner av eksterne biblioteker, og hvis du er tvunget til å bruke en egendefinert løsning, må du implementere den ved hjelp av PHP PSR-er.
En liste over alle tilgjengelige standarder er tilgjengelig på hovednettstedet PHP-FIG. Utvidede standarder med praktiske beskrivelser er tilgjengelige i en rekke formater fra PHP Den riktige måten hjemmeside.
De beste bibliotekene som er i samsvar med PHP-FIG-standardene, er oppført på PHP-ligaen nettsted.

2. Ikke låse composer.json-versjonene av avhengighetene dine

I prosjekter som bruker avhengighetsbehandler Komponist oppstår det ofte en situasjon der man etter en lang periode med støtte og vedlikehold av produkt i produksjonsmiljøet er det behov for å implementere funksjonelle endringer uten å bygge om hele arkitekturen. Som oftest overtas prosjektet da av en programmerer, hvis oppgave er å starte det lokale utviklingsmiljøet og begynne å jobbe med tickets. Basert på composer.lock filen, kan utvikleren gjenopprette prosjektet til den tilstanden det var i produksjonsmiljøet, men enhver endring i composer.json filen, f.eks. ved å legge til biblioteket, vil føre til en kaskade av feil som vil øke den faktiske implementeringstiden for en ny team medlem til organisasjonen samt tidspunktet for utvikling av løsningen.

Hvordan kan jeg unngå det?

Når applikasjonen er stabil, bør kodevedlikeholderen låse versjonene av bibliotekene i composer.json filen og lage en tydelig prosedyre som beskriver hvordan versjonene skal oppgraderes ved behov i fremtiden.

Vurder også å kjøre en mekanisme for å sjekke sikkerhetsstatusen til bibliotekene som brukes, og automatisere prosessen med å levere sikkerhetsoppdateringer.
Ved hjelp av gratis verktøy som Dependabotkan vi både opprettholde en konsistent og håndterbar versjonsinfrastruktur for avhengige biblioteker og gi en sikkerhetsgaranti for applikasjonen vår.

3. Dårlig innsamling av krav

> Det er bare en CRUD, så hvorfor bry seg?

> Det finnes et bibliotek som gjør akkurat det!

I PHP er det lett å havne i glemselens virvel når man implementerer forretningslogikk for produkter. I årenes løp har det vært hundrevis av prosjekter som [oppretter administrative paneler for å administrere datamodeller] (https://backpackforlaravel.com/), [genererer Google Analytics-lignende visninger] (https://github.com/Kunstmaan/KunstmaanDashboardBundle) eller [løser PHPs asynkroniseringsproblemer] (https://laravel.com/docs/9.x/octane) med et trylleslag (OK, med en enkelt kommandolinjespørring).
PHP-verdenen er full av ferdige implementasjoner som fungerer 99,9% av tiden.
Det 0.1% er der forretningslogikken kolliderer med de funksjonelle begrensningene i bibliotekene som brukes.
Det er disse såkalte "throw-ins" som er vanskeligst å implementere på slutten av prosjektet.

Hvordan kan jeg unngå det?

Det er umulig å finne den gylne middelvei mellom over- og underengineering uten å ha en god forståelse av produktets forretningsområde.
Ved å starte utviklingsteam Ved å være tidlig ute i produktfasen og være proaktiv i samarbeidet med produkteieren, kan du minimere risikoen for å bruke en løsning som ikke vil fungere som en langsiktig investering.

4. Kutte kostnader ved å unngå å skrive tester

PHP er ikke perfekt, det er helt sikkert. Manglene når det gjelder statisk typing, manglende generisk støtte og fortsatt støtte for arkaiske metoder er fortsatt en kilde til spøk blant programmerere. I noen tid har imidlertid PHP-utviklere har fått stadig kraftigere verktøy som PHPStan, Xdebug, PHP-CS-Fixer som gjør at de kan opprettholde konsistens og statisk typing - og dermed unngå mange feil. Likevel er det for lite fokus på tester, og når de implementeres riktig, gir de rask avkastning på investeringen i form av
- reduksjon av regresjonsfeil
- økt bevissthet om produktenes egenskaper
- øke utviklerens følelse av eierskap til koden

Hvordan kan jeg unngå det?

Ikke spar på kostnadene ved testing. Det er ikke så vanskelig å skrive enkle Behat-skript, du trenger ikke å skrive komplekse ende-til-ende-tester med en gang eller gå inn i implementasjonsdetaljer og enhetsteste hver eneste metode.
En enkel Behat-test beskrevet i et naturlig domenespråk er ofte mer verdt enn den mest omhyggelig skrevne ende-til-ende-test.

5. Tar ikke hensyn til moderne arkitekturmønstre

Den PHP språk og de to kraftigste rammeverkene Laravel og Symfony er fullt egnet til å skape en moderne, funksjonell og ikke minst høytytende arkitektur. Støtten for ulike meldingskø-systemer og den stadig raskere PHP ytelsesforbedringer fra versjon til versjon gjør at vi enkelt kan lage mikrotjenester basert på mikrorammeverk. For det meste er vi imidlertid fortsatt avhengige av monolittiske systemer. Det er ikke noe galt i det, men når vi vurderer å utvikle slike systemer, må vi være nøye med domenegrensene og bestemme grensesnittet mellom nye løsninger og eldre deler av systemet.

Hvordan kan jeg unngå det?

Ved utvikling av enhver PHP er det verdt å se nærmere på dagens løsninger, skape globale grensesnitt for datakommunikasjon og implementere nye funksjoner ved hjelp av de nyeste teknikkene og fremgangsmåtene. En av de mest populære løsningene som brukes i praksis, er Strangler-mønster.