Practica și viitorul PHP

Cum afectează introducerea noilor versiuni PHP proiectele existente cu o bază de cod mai veche?

Stefan: Acest lucru depinde în mare măsură de cât de actualizate sunt infrastructura și codul proiectului. Dacă proiectul rulează pe o versiune PHP mai veche sau pe un sistem de operare învechit, sau dacă sunt utilizate biblioteci învechite, efortul de migrare la actualizarea la o versiune PHP actuală este de obicei semnificativ mai mare. Pot apărea incompatibilități, funcțiile sau sintaxa învechite trebuie adaptate, iar dependențele trebuie verificate și actualizate dacă este necesar.

Dacă codul a fost adaptat continuu la noile versiuni PHP și la alte dependențe, efortul pentru o actualizare este, desigur, semnificativ mai mic, iar migrarea este, de obicei, lipsită de probleme.

Sebastian: Dacă diferența dintre versiunea PHP utilizată în prezent și cea nouă este mică, efortul de migrare este redus semnificativ. Trebuie luate în considerare mai puține funcții învechite sau schimbări de sintaxă. Un salt mare de versiune, de exemplu de la PHP 5 la PHP 8, pe de altă parte, poate necesita ajustări majore ale codului și ale dependențelor. În acest caz, este necesară o testare extinsă.

Stefan: Proiectele ar trebui să urmeze ciclul de lansare al PHP și, de exemplu, să instaleze versiunea PHP lansată în toamna anului precedent în vara unui anumit an. Astfel, codul rămâne actualizat, efortul de migrare este ușor de gestionat și riscul de incompatibilități este minimizat.

Ce rol joacă în prezent programarea asincronă în proiectele PHP?

Stefan: PHP a procesat întotdeauna cererile într-un proces separat al sistemului de operare. Aceasta înseamnă că cererile individuale sunt bine izolate unele de altele. Această izolare asigură securitatea și stabilitatea, deoarece erorile sau pierderile de memorie dintr-un proces nu le afectează pe celelalte. Cu toate acestea, trecerea de la un proces la altul este asociată cu o anumită cantitate de supraîncărcare, care reduce performanța atunci când există multe cereri simultane.

O alternativă la această abordare este asincronia, care a devenit populară cu Node.js, de exemplu. Aici, izolarea proceselor este evitată în mod deliberat pentru a obține un randament mai mare. În schimb, se încearcă să se aștepte cât mai puțin posibil pentru I/O, dar în schimb să se efectueze alte activități productive în procesul în curs de desfășurare. Cu toate acestea, acest lucru necesită I/O fără blocare, astfel încât procesul să nu fie blocat și, prin urmare, să elibereze imediat din nou CPU.

Deși PHP suportă, în general, asincronia, extensii importante precum mysqli nu sunt încă neblocante. Aceasta înseamnă că aplicațiile dezvoltate în PHP nu beneficiază de avantajele de performanță, chiar dacă codul este conceput similar cu Node.js. Numai atunci când extensiile relevante vor fi, de asemenea, non-blocking în viitor, această abordare poate fi urmărită în mod semnificativ. Cu toate acestea, apare problema că, în cazul unui blocaj, nu mai este posibilă reconstituirea stării exacte a aplicației, și anume care activitate a fost deja efectuată și care nu. Aceasta poate fi o problemă în cazul efectelor secundare, cum ar fi trimiterea de e-mailuri.

Ce rol joacă PHP în combinație cu microserviciile și care sunt cele mai recente evoluții în acest domeniu?

Stefan: PHP este deosebit de potrivit pentru implementarea și utilizarea microserviciilor, deoarece cererile HTTP pot fi procesate într-un mod foarte ușor.

Arne: Cadrele moderne sprijină această abordare prin faptul că lucrează din ce în ce mai eficient și se asigură că trebuie să fie executat cât mai puțin cod de cadru posibil înainte de a fi executată logica de afaceri reală.

Stefan: În practică, observăm adesea că dezvoltatorii implementează microservicii cu PHP, dar utilizează aceleași straturi de abstractizare ca pentru aplicațiile monolitice. Ca urmare, potențialul microserviciilor nu este adesea utilizat pe deplin. Observăm o tendință clară către servicii mai mici și mai specializate, ca urmare a cloud computing-ului și a disponibilității tot mai mari a serviciilor specializate.

Există cadre sau biblioteci noi care vi se par deosebit de interesante?

Stefan: În mod regulat apar noi cadre și biblioteci interesante, pe care le analizăm cu mare interes. Cu toate acestea, în activitatea noastră de consultanță recomandăm de obicei software consacrat și testat, pentru a evita riscurile.

Arne: Framework-uri precum Symfony și Laravel sunt testate, stabile și oferă un nivel ridicat de securitate, precum și o comunitate mare. Prin urmare, cadrele noi întâmpină dificultăți în a se impune în fața acestor soluții consacrate.

În opinia dvs., care modele de proiectare sunt deosebit de eficiente pentru dezvoltarea PHP?

Stefan: Cred că modelele de proiectare sunt foarte importante deoarece pot accelera și simplifica comunicarea între dezvoltatori. Am susținut recent prezentarea "Essential Design Patterns" la Conferința internațională PHP. Puteți vizualiza slide-urile la adresa the-fluent-developer.com. Modelele pe care le-am prezentat în această prezentare sunt exact cele pe care le consider deosebit de importante pentru dezvoltarea PHP.

Cât de importante sunt arhitecturile bazate pe evenimente pentru aplicațiile PHP de mari dimensiuni și care este cel mai bun mod de a le implementa?

Stefan: Deoarece lumea reală este bazată pe evenimente, o pot modela foarte bine cu o arhitectură condusă de evenimente.

Sebastian: Astfel de procese sunt implementate folosind cod simplu, ușor de înțeles. Acest lucru nu este doar ușor de implementat, ci și excelent pentru testare.

Stefan: Introducerea unei arhitecturi bazate pe evenimente se dovedește a fi mai puțin complicată decât se presupunea inițial. Prin urmare, oferim cursuri de formare specifice pentru a sprijini echipele în implementarea și integrarea acestor concepte în aplicațiile PHP existente sau noi.

Ce principii recomandați pentru a asigura mentenabilitatea și testabilitatea pe parcursul întregului ciclu de dezvoltare?

Sebastian: Este foarte dificil fără teste automate.

Ștefan: Nu vrem ca utilizatorii finali să testeze.

Sebastian: Dezvoltarea ar trebui să aibă loc pas cu pas și în cicluri scurte, astfel încât modificările să poată fi integrate și testate rapid și clar. Acest lucru înseamnă că starea software-ului poate fi monitorizată continuu, iar erorile sunt recunoscute într-un stadiu incipient.

Arne: Un alt principiu important este revizuirea periodică, automată, a stării actuale a software-ului. Acest lucru garantează că noile modificări nu au efecte secundare nedorite. Oferim cursuri de formare care constituie baza pentru acest lucru.

Sebastian: În plus, dependențe precum PHP ar trebui să fie actualizate în mod continuu, așa cum a sugerat Stefan mai devreme, pentru a menține software-ul la zi.

Stefan: Un alt factor cheie de succes este faptul că întreaga echipă definește un standard de calitate comun care este susținut de toți cei implicați, inclusiv de cei din afara departamentului de dezvoltare. Acest lucru face din calitate un obiectiv obligatoriu care poate fi aplicat pe parcursul întregului proces de dezvoltare și asigură mentenabilitatea și testabilitatea pe termen lung.

Ce instrumente sau abordări există pentru a face codul modern și pregătit pentru viitor?

Stefan: Arne și cu mine suntem obligați prin lege să menționăm PHPUnit aici (râsete).

Sebastian: Fără teste, nu există nicio garanție că modificările viitoare nu vor cauza erori neobservate. Și da, trebuie să menționez PHPUnit ca un cadru de testare.

Instrumente precum PHPStan sau Psalm analizează codul fără a-l executa și ajută la detectarea erorilor de programare, cum ar fi inconsistențele de tip, într-un stadiu incipient.

Arne: PHP-CS-Fixer sau PHP_CodeSniffer pot fi utilizate pentru a se asigura că codul este formatat în mod consecvent. Acest lucru facilitează colaborarea în cadrul echipei și face codul mai ușor de înțeles pentru alți dezvoltatori. Rector este un instrument pentru modernizarea automată a codului existent. De exemplu, acesta poate înlocui sintaxa veche cu noi caracteristici ale limbajului sau poate adapta codul la cele mai bune practici actuale sau chiar la noile versiuni ale cadrului. În acest fel, codul rămâne compatibil cu noile versiuni PHP și beneficiază de îmbunătățirile aduse limbajului.

Stefan: Suntem convinși că instrumentele open source menționate sunt o alegere la fel de bună, dacă nu chiar mai bună, decât produsele comerciale.

Cu toate acestea, dincolo de instrumente, aș dori în primul rând să recomand cele mai bune practici: Codul curat și principiile SOLID asigură că software-ul rămâne clar structurat, inteligibil și flexibil. Acest lucru face codul mai ușor de întreținut, personalizabil și poate fi dezvoltat eficient și în viitor. Astfel, baza de cod rămâne modernă și pregătită pentru viitor.

În prezent, integrarea inteligenței artificiale în mediile noastre de dezvoltare ne extinde considerabil setul de instrumente. De exemplu, putem cere IDE-ului să explice, să optimizeze sau să modernizeze codul afișat în prezent. Aceste noi posibilități sunt extrem de interesante, dar rămâne de văzut în ce măsură se vor dovedi în practică.

Cum pot dezvoltatorii să reducă datoria tehnică din proiectele moștenite într-un mod direcționat și eficient?

Arne: Primul pas este identificarea și eliminarea sistematică a codului neutilizat. Instrumentele pot ajuta la găsirea codului care nu mai este executat, în timp ce discuțiile cu părțile interesate permit "închiderea" caracteristicilor care nu mai sunt necesare. Acest lucru nu numai că reduce complexitatea, dar creează și spațiu mental pentru echipă.

Stefan: Reducerea datoriilor tehnice se realizează prin schimbări mici, ușor de gestionat. Punctele critice pot fi identificate prin intermediul fișierelor jurnal pentru a pregăti codul pentru o actualizare la o nouă versiune PHP sau framework, de exemplu. Uitați-vă la deprecieri și avertismente și încercați să scăpați de ele. Părțile individuale ale aplicației pot fi înlocuite treptat cu componente moderne, nou dezvoltate.

Sebastian: Testele automatizate asigură stabilitatea și minimizează riscurile prin regresii.

Ștefan: Această combinație de curățare direcționată, modernizare treptată și procese robuste creează o bază de cod întreținută în mod sustenabil. Costurile de întreținere scad, stabilitatea sistemului crește, iar echipele câștigă timp pentru a se concentra asupra noilor cerințe - o rentabilitate clară a investiției pentru orice companie.

Cum tratați cadrele și bibliotecile PHP învechite ca parte a unei strategii de modernizare?

Stefan: Dacă există o cale oficială de migrare pentru cadrul utilizat, este recomandabil să o folosiți ca bază pentru modernizare.

Sebastian: Instrumentele specializate, cum ar fi Rector și refactorizările automate, precum și funcțiile susținute de inteligența artificială în mediile de dezvoltare moderne ajută la efectuarea ajustărilor recurente în mod eficient și cu erori minime.

Arne: În ceea ce privește bibliotecile, ar trebui să verificați întotdeauna mai întâi dacă o anumită bibliotecă mai este necesară. Poate că o versiune PHP mai nouă oferă funcționalitatea sa direct în limbaj, sau funcționalitatea în sine nu mai este necesară, dar existența bibliotecii a fost pur și simplu uitată. În acest caz, aceasta ar trebui eliminată pentru a eficientiza baza de cod. Dacă biblioteca este încă relevantă, este important să se evalueze dacă este posibilă o actualizare.

Ștefan: Dacă devine necesar să se treacă la o bibliotecă alternativă, este recomandabil să se utilizeze branch-by-abstraction pentru această schimbare. Mai ales dacă nu a fost încă implementată o izolare consecventă a dependențelor utilizând inversarea dependențelor.

Ce proceduri sau cadre sunt deosebit de utile pentru modernizarea treptată?

Ștefan: Este important să acționăm preventiv și să recunoaștem ajustările necesare într-un stadiu incipient. Prin integrarea în timp util a modificărilor planificate în procesele noastre de dezvoltare, creăm condițiile necesare pentru a le putea pune în aplicare într-un interval de timp rezonabil și fără presiuni inutile. Acest lucru ne permite să evităm riscurile majore și refacerile costisitoare.

Sebastian: Pentru a putea evalua în mod fiabil efectele modificărilor, efectuăm mai întâi testele existente ale proiectului într-un mediu separat cu noua versiune PHP sau framework. În acest fel, ne asigurăm că potențialele probleme sunt recunoscute într-un stadiu incipient, fără a afecta sistemul de producție în funcțiune.

În cazul în care proiectul nu are o acoperire suficientă a testelor, așa-numitele teste de caracterizare pot fi utilizate ca o măsură de protecție temporară. Aceste teste ajută la compararea comportamentului actual al software-ului în diferite medii și asigură astfel că modificările efectuate nu provoacă efecte secundare nedorite.

Prin ce diferă dezvoltarea PHP în mediile cloud de mediile de servere tradiționale?

Arne: Containerele pot fi utilizate fără probleme și în mediile clasice de servere și, invers, software-ul din cloud poate fi instalat în continuare într-o mașină virtuală în mod tradițional. Cu toate acestea, avantajul decisiv al containerizării este că containerele sunt mult mai eficiente din punct de vedere al resurselor și mai flexibile decât mașinile virtuale. Acest lucru se datorează faptului că pentru acestea nu trebuie emulat niciun hardware și nu este necesar niciun sistem de operare complet în container. Aceasta înseamnă că aplicația poate fi pornită mai rapid și scalată mai eficient. Acesta este motivul pentru care utilizarea containerelor devine din ce în ce mai populară, indiferent dacă rulează pe bare metal, în VM-uri sau în cloud.

Stefan: Software-ul care urmează să fie operat în cloud ar trebui să fie mai modularizat pentru a profita la maximum de flexibilitatea și scalabilitatea cloud-ului. O structură modulară facilitează dezvoltarea și testarea componentelor individuale independent unele de altele și înlocuirea sau extinderea acestora în funcție de necesități. De asemenea, în cloud sunt disponibile numeroase servicii specializate, cum ar fi pentru baze de date sau cozi de mesaje, care pot fi integrate în mod direcționat. Acest lucru accelerează dezvoltarea și simplifică întreținerea, dar poate crește și costurile de exploatare.

Trecerea la containerizare poate părea inițial foarte dificilă și uneori dureroasă pentru echipă, deoarece multe probleme tehnice și organizatorice devin evidente încă de la începutul proiectului. Dificultățile care apar la operarea software-ului în containere trebuie abordate din timp, ceea ce face tranziția mai complexă, dar asigură o mai mare stabilitate și transparență pe termen lung.

Ce bune practici specifice PHP recomandați pentru integrarea și implementarea continuă?

Sebastian: Standardele industriale pentru CI/CD sunt fundamental independente de limbajul de programare utilizat. Principiile și cele mai bune practici, cum ar fi construcțiile automate, testarea continuă și implementările repetabile, se aplică în mod egal tuturor proiectelor software moderne.

Arne: Pentru a se asigura că starea software a unui proiect poate fi reprodusă în orice moment, fișierele composer.lock și composer.json ar trebui să fie verificate în sistemul de gestionare a versiunilor. În composer.json, versiunea PHP necesară trebuie să fie configurată și documentată în același mod ca și extensiile PHP necesare.

Ștefan: Cu PIE (PHP Installer for Extensions), proiectul PHP lucrează în prezent la o soluție pentru a elimina lacunele anterioare în gestionarea extensiilor PHP. În timp ce Composer poate declara dependențe pentru extensii, dar nu le poate instala singur, PIE permite pentru prima dată un flux de lucru modern, asemănător cu Composer, pentru instalarea și gestionarea extensiilor PHP.

Ce provocări specifice PHP apar atunci când se utilizează Kubernetes?

Stefan: Containerele sunt orchestrate cu Kubernetes, de exemplu containerele al căror proces s-a blocat sunt repornite.

Arne: Containerele sunt concepute pentru a încapsula exact un proces care rulează și care rămâne activ pe întreaga durată de viață a containerului. Dacă acest proces principal este oprit, containerul este, de asemenea, oprit și eliminat.

Stefan: Deoarece interpretorul PHP nu este conceput ca un proces care rulează permanent, acesta nu este potrivit ca proces principal pentru un container. Ca și în cazul conceptelor de operare fără containere, soluția constă în utilizarea FastCGI Process Manager (PHP-FPM): acesta poate fi executat ca proces cu durată lungă de viață într-un container și deleagă executarea codului PHP pentru cererile primite interpretului PHP, care procesează cererile în procese separate.

În acest context, devine clar de ce rularea unei aplicații PHP într-un container sub Kubernetes are provocări ușor diferite față de, de exemplu, o aplicație Node.js, care are propriul său proces de server care rulează permanent.

Ce rol joacă Infrastructure as Code (IaC) în proiectele PHP în medii DevOps?

Arne: Infrastructure as Code (IaC) este independent de limbajul de programare utilizat și joacă un rol central în automatizarea instalării și configurării mediului de dezvoltare și operare. Scopul este de a putea configura mediul necesar pentru a rula software-ul în mod reproductibil și fiabil în orice moment.

Stefan: Pe un server clasic, scalarea unei aplicații PHP se realizează inițial prin adaptarea configurației PHP FPM, de exemplu prin creșterea numărului de procese worker. Dacă cerințele continuă să crească, scalarea orizontală se realizează prin dotarea serverelor suplimentare cu alte instanțe PHP FPM. Cel târziu în acest moment, Infrastructure as Code (IaC) devine indispensabilă, deoarece administrarea și configurarea manuală a infrastructurii consumă prea mult timp și este predispusă la erori.