Een project onderhouden in PHP: 5 fouten om te vermijden

PHPheeft, net als andere talen, enkele nadelen die niets waard zijn als het gaat om het beheren van een IT project waarbij PHP is de leidende taal.

Hieronder hebben we er een lijst van gemaakt, samen met tips om ze te vermijden.

1. Aanbevelingen voor PHP-standaarden niet volgen

PHP wordt beschouwd als een "gemakkelijke taal" omdat het een zeer lage instapdrempel heeft. Dit resulteert in een groot verschil in coderingsstandaarden en hoe globale interfaces worden geïmplementeerd in verschillende externe bibliotheken. In een poging om orde te scheppen, werd een set standaarden geïntroduceerd. Deze beschrijven een reeks manieren waarop de ontwikkelaar van de implementatie kan voldoen aan elke reeks beperkingen die door de standaard worden vereist. Een eenvoudig voorbeeld voor Gebeurtenis Dispatcher:

Listener - Een Listener is een PHP callable die verwacht dat er een Event wordt doorgegeven. Nul of meer Listeners kunnen dezelfde Event doorgegeven krijgen. Een Listener KAN naar keuze ander asynchroon gedrag enqueue-en.

Met behulp van deze standaard kan elke ontwikkelaar die de nomenclatuur van PSR-compiant gebruikt, niet alleen eenvoudig communiceren met maar ook code met andere ontwikkelaars.
Deze standaarden in de praktijk brengen, bijvoorbeeld door gebruik te maken van PHP De juiste manier richtlijnen en bibliotheken die globale PSR-interfaces ondersteunen, kunnen PHP ontwikkelaars om zich sneller aan te passen aan veranderingen in functionele, architecturale en infrastructuureisen.

Hoe kan ik het vermijden?

Denk er als beheerder van de codebase altijd aan om bewezen en stabiele versies van externe bibliotheken te gebruiken en als je gedwongen wordt om een aangepaste oplossing te gebruiken, implementeer deze dan met PHP PSR's.
Een lijst van alle beschikbare standaarden is beschikbaar op de hoofdwebsite PHP-FIG. Uitgebreide standaarden met praktische beschrijvingen zijn beschikbaar in verschillende formaten bij de PHP De juiste manier homepage.
De beste bibliotheken die voldoen aan de PHP-FIG standaard staan op de PHP Divisie website.

2. De versies van je composer.json afhankelijkheden niet vergrendelen

In projecten die dependency manager gebruiken Componist is er vaak een situatie waarin na een lange periode van ondersteuning en onderhoud van de product in de productieomgeving is het nodig om functionele wijzigingen door te voeren zonder de hele architectuur opnieuw op te bouwen. Meestal wordt het project dan overgenomen door een programmeur, wiens taak het is om de lokale ontwikkelomgeving te starten en aan tickets te gaan werken. Op basis van de componist.slot bestand kan de ontwikkelaar het project herstellen naar de staat waarin het zich bevond in de productieomgeving, maar elke wijziging aan de composer.json bestand, bijvoorbeeld door de bibliotheek toe te voegen, zal een cascade van fouten veroorzaken die de werkelijke implementatietijd van een nieuwe team lid van de organisatie en de tijd die nodig is voor de ontwikkeling van de oplossing.

Hoe kan ik het vermijden?

Als de applicatie eenmaal stabiel is, moet de codebeheerder de versies van de bibliotheken in de composer.json bestand en creëer een duidelijke procedure die beschrijft hoe je hun versies kunt upgraden als dat in de toekomst nodig is.

Overweeg ook om een mechanisme te gebruiken om de beveiligingsstatus van de gebruikte bibliotheken te controleren en het proces van het leveren van beveiligingsupdates te automatiseren.
Gebruik gratis tools zoals Dependabotkunnen we zowel een consistente, beheerbare versie-infrastructuur voor afhankelijke bibliotheken onderhouden als een veiligheidsgarantie voor onze applicatie bieden.

3. Slechte eisenverzameling

> Het is gewoon een CRUD, waarom moeite doen?

> Er is een bibliotheek die precies dat doet!

In de PHP domein is het gemakkelijk om in de draaikolk van vergeetachtigheid te vallen bij het implementeren van productbedrijfslogica. In de loop der jaren zijn er honderden projecten geweest die [administratieve panelen maken om datamodellen te beheren](https://backpackforlaravel.com/), [Google Analytics-achtige weergaven genereren](https://github.com/Kunstmaan/KunstmaanDashboardBundle) of [de async-problemen van PHP oplossen](https://laravel.com/docs/9.x/octane) met een simpele druk op de knop (OK, met een enkele opdrachtregelquery).
De PHP wereld zit vol met kant-en-klare implementaties die 99,9% van de tijd werken.
Dat 0.1% is waar bedrijfslogica botst met de functionele beperkingen van de gebruikte bibliotheken.
Het zijn deze zogenaamde "throw-ins" die het moeilijkst te implementeren zijn aan het einde van het project.

Hoe kan ik het vermijden?

Er is geen kans om de gulden middenweg te vinden tussen over- en onderengineering zonder een goed begrip van het bedrijfsdomein van het product.
Door te beginnen ontwikkelingsteam Door vroeg in de productfase te beginnen en proactief samen te werken met de producteigenaar, kun je het risico op een oplossing die niet werkt als langetermijninvestering minimaliseren.

4. Kosten besparen door geen tests te schrijven

PHP is niet perfect, dat is zeker. De tekortkomingen op het gebied van statische typing, het gebrek aan ondersteuning voor generics en de voortdurende ondersteuning voor archaïsche methoden zijn nog steeds een bron van grappen onder programmeurs. Echter, voor enige tijd PHP ontwikkelaars hebben steeds krachtigere hulpmiddelen gekregen zoals PHPStan, Xdebug, PHP-CS-Fixer die hen in staat stellen om consistentie en statische typing te behouden - waardoor veel bugs worden vermeden. Toch wordt er te weinig aandacht besteed aan testen en die leveren, als ze goed geïmplementeerd zijn, snel rendement op in de vorm van
- reductie van regressiefouten
- Grotere bekendheid van productmogelijkheden
- Het gevoel van code-eigendom bij ontwikkelaars vergroten

Hoe kan ik het vermijden?

Bespaar niet op testen. Het schrijven van eenvoudige Behat scripts is echt niet zo moeilijk, je hoeft niet meteen complexe end-to-end tests te schrijven of je te verdiepen in implementatiedetails en elke methode te unittesten.
Een eenvoudige Behat test beschreven in natuurlijke domeintaal is vaak meer waard dan de meest zorgvuldig geschreven end-to-end test.

5. Geen rekening houden met moderne architectuurpatronen

De PHP taal en zijn twee krachtigste frameworks Laravel en Symfony zijn volledig geschikt voor het maken van een moderne, functionele en vooral goed presterende architectuur. De ondersteuning voor verschillende berichtwachtrijsystemen en de steeds snellere PHP prestatieverbeteringen van versie tot versie stelt ons in staat om eenvoudig microservices te maken op basis van microframeworks. Voor het grootste deel vertrouwen we echter nog steeds op monolithische systemen. Daar is niets mis mee, maar als we de ontwikkeling van dergelijke systemen overwegen, moeten we goed letten op de domeingrenzen en het raakvlak tussen nieuwe oplossingen en oudere delen van het systeem bepalen.

Hoe kan ik het vermijden?

Bij het ontwikkelen van een PHP website is het de moeite waard om de huidige oplossingen onder de loep te nemen, globale interfaces voor datacommunicatie te creëren en nieuwe functionaliteiten te implementeren met behulp van de nieuwste technieken en praktijken. Een van de meest gebruikte oplossingen in de praktijk is Wurgpatroon.