Vedligeholdelse af et projekt i PHP: 5 fejl, du skal undgå

PHPhar ligesom andre sprog nogle ulemper, som ikke er noget værd, når det handler om at styre en IT projekt hvor PHP er det førende sprog.

Nedenfor har vi samlet en liste over dem sammen med tips til, hvordan man undgår dem.

1. Følger ikke anbefalingerne i PHP-standarderne

PHP betragtes som et "nemt sprog", fordi det har en meget lav adgangsbarriere. Det resulterer i en stor forskel i kodningsstandarder og i, hvordan globale grænseflader implementeres i forskellige eksterne biblioteker. I et forsøg på at skabe orden blev der indført et sæt standarder. De beskriver en række måder, hvorpå udvikleren af implementeringen kan opfylde ethvert sæt af begrænsninger, der kræves af standarden. Et simpelt eksempel for Event-dispatcher:

Lytter - En lytter er en hvilken som helst PHP der forventer at få overdraget en hændelse. Nul eller flere lyttere kan få overdraget den samme hændelse. En lytter KAN sætte en anden asynkron adfærd i kø, hvis den ønsker det.

Ved hjælp af denne standard kan alle udviklere, der bruger PSR-kompatibel nomenklatur, nemt ikke kun kommunikere med, men også Kode med andre udviklere.
At omsætte disse standarder til praksis, for eksempel ved at bruge PHP på den rigtige måde retningslinjer og biblioteker, der understøtter globale PSR-grænseflader, giver mulighed for PHP-udviklere at tilpasse sig hurtigere til ændringer i funktionelle, arkitektoniske og infrastrukturelle krav.

Hvordan kan jeg undgå det?

Som vedligeholder af kodebasen skal du altid huske at bruge gennemprøvede og stabile versioner af eksterne biblioteker, og hvis du er tvunget til at bruge en brugerdefineret løsning, skal du implementere den ved hjælp af PHP PSR'er.
En liste over alle tilgængelige standarder er tilgængelig på hovedwebstedet PHP-FIG. Udvidede standarder med praktiske beskrivelser er tilgængelige i en række forskellige formater fra PHP på den rigtige måde hjemmeside.
De bedste biblioteker, der er i overensstemmelse med PHP-FIG-standarderne, er listet på PHP Liga hjemmeside.

2. Du låser ikke dine composer.json-afhængighedsversioner

I projekter, der bruger dependency manager Komponist er der ofte en situation, hvor der efter en lang periode med støtte og vedligeholdelse af produkt I produktionsmiljøet er der behov for at implementere funktionelle ændringer uden at genopbygge hele arkitekturen. Oftest overtages projektet derefter af en programmør, hvis opgave er at starte det lokale udviklingsmiljø og begynde at arbejde på tickets. Baseret på composer.lock fil, kan udvikleren gendanne projektet til den tilstand, det var i produktionsmiljøet, men enhver ændring af composer.json fil, f.eks. ved at tilføje biblioteket, vil forårsage en kaskade af fejl, som vil øge den faktiske tid for implementering af en ny hold medlem til organisationen samt tidspunktet for udvikling af løsningen.

Hvordan kan jeg undgå det?

Når applikationen er stabil, bør kodevedligeholderen låse versionerne af bibliotekerne i composer.json fil og skabe en klar procedure, der beskriver, hvordan man opgraderer deres versioner, hvis det bliver nødvendigt i fremtiden.

Overvej også at køre en mekanisme til at kontrollere sikkerhedsstatus for de anvendte biblioteker og automatisere processen med at levere sikkerhedsopdateringer.
Brug gratis værktøjer som f.eks. Dependabotkan vi både opretholde en konsistent, håndterbar versioneringsinfrastruktur for afhængige biblioteker og give en sikkerhedsgaranti for vores applikation.

3. Dårlig indsamling af krav

> Det er bare en CRUD, hvorfor gøre sig umage?

> Der findes et bibliotek, der gør præcis det!

I PHP domæne, er det let at falde i glemslens hvirvelstrøm, når man implementerer produktets forretningslogik. I årenes løb har der været hundredvis af projekter, der [opretter administrative paneler til at styre datamodeller](https://backpackforlaravel.com/), [genererer Google Analytics-lignende visninger](https://github.com/Kunstmaan/KunstmaanDashboardBundle) eller [løser PHP's async-problemer](https://laravel.com/docs/9.x/octane) med et trylleslag (OK, med en enkelt kommandolinjeforespørgsel).
PHP-verdenen er fuld af færdige implementeringer, der fungerer 99,9% af tiden.
Det 0.1% er der, hvor forretningslogikken kolliderer med de funktionelle begrænsninger i de anvendte biblioteker.
Det er disse såkaldte "throw-ins", der er de sværeste at implementere i slutningen af projektet.

Hvordan kan jeg undgå det?

Der er ingen chance for at finde den gyldne middelvej mellem overengineering og underengineering uden en ordentlig forståelse af produktets forretningsområde.
Ved at starte udviklingsteam ved at være proaktive i samarbejdet med produktejeren, kan du minimere risikoen for at bruge en løsning, der ikke fungerer som en langsigtet investering.

4. Reducer omkostningerne ved at undgå at skrive tests

PHP er ikke perfekt, det er helt sikkert. Dens mangler med hensyn til statisk typning, manglende generisk understøttelse og fortsat understøttelse af forældede metoder er stadig en kilde til vittigheder blandt programmører. Men i nogen tid PHP-udviklere har fået flere og flere kraftfulde værktøjer som PHPStan, Xdebug, PHP-CS-Fixer der giver dem mulighed for at opretholde konsistens og statisk typning - og dermed undgå mange fejl. Alligevel er der for lidt opmærksomhed på test, og når de implementeres korrekt, resulterer de i et hurtigt afkast af investeringen i form af
- reduktion af regressionsfejl
- øget bevidsthed om produktfunktioner
- øge udviklerens følelse af kodeejerskab

Hvordan kan jeg undgå det?

Spar ikke på omkostningerne til test. Det er ikke så svært at skrive simple Behat-scripts, du behøver ikke at skrive komplekse end-to-end-tests med det samme eller gå i detaljer med implementeringen og unit-teste hver eneste metode.
En simpel Behat-test beskrevet i et naturligt domænesprog er ofte mere værd end den mest omhyggeligt skrevne end-to-end-test.

5. Overvejer ikke moderne arkitekturmønstre

Den PHP sprog og dens to stærkeste frameworks Laravel og Symfony er fuldt ud egnede til at skabe en moderne, funktionel og vigtigst af alt højtydende arkitektur. Understøttelsen af forskellige meddelelseskø-systemer og den stadig hurtigere PHP Forbedringer af ydeevnen fra version til version giver os mulighed for nemt at skabe mikrotjenester baseret på mikroframeworks. For det meste er vi dog stadig afhængige af monolitiske systemer. Det er der ikke noget galt med, men når vi overvejer at udvikle sådanne systemer, skal vi være meget opmærksomme på domænegrænserne og bestemme grænsefladen mellem nye løsninger og ældre dele af systemet.

Hvordan kan jeg undgå det?

Når du udvikler en PHP er det værd at se nærmere på de nuværende løsninger, skabe globale grænseflader til datakommunikation og implementere nye funktioner ved hjælp af de nyeste teknikker og fremgangsmåder. En af de mest populære løsninger, der bruges i praksis, er Strangler-mønster.