Underhåll av ett projekt i PHP: 5 misstag att undvika

PHPhar, precis som andra språk, vissa nackdelar som inte är värda någonting när det gäller att hantera ett IT projekt där PHP är det ledande språket.

Nedan har vi sammanställt en lista över dessa, tillsammans med tips om hur du undviker dem.

1. Följer inte rekommendationerna för PHP-standarder

PHP anses vara ett "enkelt språk" eftersom det har ett mycket lågt inträdeshinder. Detta resulterar i stora skillnader i kodningsstandarder och hur globala gränssnitt implementeras i olika externa bibliotek. I ett försök att bringa ordning infördes en uppsättning standarder. Dessa beskriver en uppsättning sätt på vilka utvecklaren av implementationen kan uppfylla alla begränsningar som krävs enligt standarden. Ett enkelt exempel för Event Dispatcher:

Lyssnare - En lyssnare är en PHP som förväntar sig att få en händelse skickad till sig. Noll eller fler lyssnare kan få samma händelse. En lyssnare KAN sätta något annat asynkront beteende i kö om den så önskar.

Med hjälp av denna standard kan varje utvecklare som använder PSR-nomenklaturen enkelt inte bara kommunicera med utan också kod med andra utvecklare.
Tillämpa dessa standarder i praktiken, till exempel genom att använda PHP på rätt sätt riktlinjer och bibliotek som stöder globala PSR-gränssnitt, gör det möjligt PHP utvecklare snabbare kunna anpassa sig till förändringar i funktionella, arkitektoniska och infrastrukturella krav.

Hur kan jag undvika det?

Som underhållare av kodbasen ska du alltid komma ihåg att använda beprövade och stabila versioner av externa bibliotek och om du är tvungen att använda en specialbaserad lösning ska du implementera den med PHP PSR.
En lista över alla tillgängliga standarder finns på huvudwebbplatsen PHP-FIG. Utökade standarder med praktiska beskrivningar finns tillgängliga i en mängd olika format från PHP på rätt sätt hemsida.
De bästa biblioteken som överensstämmer med PHP-FIG-standarderna finns listade på PHP Liga webbplats.

2. Låser inte dina versioner av beroenden i composer.json

I projekt som använder beroendehanterare Kompositör uppstår ofta en situation där man efter en lång period av stöd och underhåll av Produkt I produktionsmiljön finns det behov av att genomföra funktionella förändringar utan att bygga om hela arkitekturen. Oftast tas projektet då över av en programmerare, vars uppgift är att starta den lokala utvecklingsmiljön och börja arbeta med ärenden. Baserat på kompositör.lås filen kan utvecklaren återställa projektet till det tillstånd som det hade i produktionsmiljön, men alla ändringar i kompositör.json t.ex. genom att lägga till ett bibliotek, kommer att orsaka en kaskad av fel som kommer att öka den faktiska tiden för implementering av en ny Team medlem till organisationen samt tiden för utveckling av lösningen.

Hur kan jag undvika det?

När programmet är stabilt bör kodunderhållaren låsa versionerna av biblioteken i kompositör.json och skapa ett tydligt förfarande som beskriver hur man uppgraderar sina versioner om det behövs i framtiden.

Överväg också att införa en mekanism för att kontrollera säkerhetsstatusen för de bibliotek som används och automatisera processen för att tillhandahålla säkerhetsuppdateringar.
Med hjälp av gratisverktyg som t.ex. Dependabotkan vi både upprätthålla en konsekvent och hanterbar infrastruktur för versionshantering för beroende bibliotek och ge en säkerhetsgaranti för vår applikation.

3. Dålig insamling av krav

> Det är bara en CRUD, varför bry sig?

> Det finns ett bibliotek som gör precis det!

I PHP är det lätt att hamna i glömskans virvel när man implementerar affärslogik för produkter. Genom åren har det funnits hundratals projekt som [skapar administrativa paneler för att hantera datamodeller](https://backpackforlaravel.com/), [genererar Google Analytics-liknande vyer](https://github.com/Kunstmaan/KunstmaanDashboardBundle) eller [löser PHP:s async-problem](https://laravel.com/docs/9.x/octane) med ett trollslag (OK, med en enda kommandoradsfråga).
PHP-världen är full av färdiga implementeringar som fungerar 99,9% av tiden.
Det 0.1% är där affärslogiken kolliderar med de funktionella begränsningarna i de bibliotek som används.
Det är dessa så kallade "throw-ins" som är svårast att implementera i slutet av projektet.

Hur kan jag undvika det?

Det finns ingen chans att hitta den gyllene medelvägen mellan överengineering och underengineering utan en ordentlig förståelse för produktens affärsområde.
By starting utvecklingsteam members early in the product phase and being proactive while working with the product owner, you can minimize the risk of the problem of using a solution that won’t work as a long-term investment.

4. Sänka kostnaderna genom att undvika att skriva tester

PHP är inte perfekt, det är ett som är säkert. Dess brister när det gäller statisk typning, avsaknad av generiskt stöd och fortsatt stöd för ålderdomliga metoder är fortfarande en källa till skämt bland programmerare. Men under en tid PHP utvecklare har fått fler och fler kraftfulla verktyg som PHPStan, Xdebug, PHP-CS-Fixare som gör det möjligt för dem att upprätthålla konsekvens och statisk typning - och därmed undvika många buggar. Ändå ägnas alltför lite uppmärksamhet åt tester och dessa, när de implementeras korrekt, resulterar i en snabb avkastning på investeringen i form av
- minskning av regressionsfel
- ökad medvetenhet om produkternas kapacitet
- öka utvecklarens känsla av att äga koden

Hur kan jag undvika det?

Dra inte ner på kostnaderna för testning. Att skriva enkla Behat-skript är verkligen inte så svårt, du behöver inte skriva komplexa end-to-end-tester direkt eller gå in på implementationsdetaljer och enhetstesta varje metod.
Ett enkelt Behat-test som beskrivs på ett naturligt domänspråk är ofta värt mer än det mest noggrant skrivna end-to-end-testet.

5. Beaktar inte moderna arkitekturmönster

Den PHP språk och dess två mest kraftfulla ramverk Laravel och Symfony är fullt lämpade för att skapa en modern, funktionell och framför allt högpresterande arkitektur. Stödet för olika system för meddelandeköer och den allt snabbare PHP prestandaförbättringar från version till version gör att vi enkelt kan skapa mikrotjänster baserade på mikroramverk. För det mesta förlitar vi oss dock fortfarande på monolitiska system. Det är inget fel med det, men när vi överväger att utveckla sådana system måste vi vara noga med domängränserna och bestämma gränssnittspunkten mellan nya lösningar och äldre delar av systemet.

Hur kan jag undvika det?

Vid utveckling av alla PHP är det värt att titta närmare på de nuvarande lösningarna, skapa globala gränssnitt för datakommunikation och implementera nya funktioner med hjälp av de senaste teknikerna och metoderna. En av de mest populära lösningarna som används i praktiken är Strangler-mönster.