Sviluppo PHP

Lavoro con entrambi. Ultimamente tendo a preferire Laravel per il suo approccio batteries included: gran parte di quello che serve a un'applicazione è già nel framework, con convenzioni chiare, e questo riduce sia il tempo di avvio sia la quantità di decisioni da prendere su componenti accessori.

Symfony resta la scelta naturale quando esiste già una codebase costruita su quel framework, o quando il progetto richiede un controllo più fine sui componenti e una struttura più esplicita. Su una migrazione, in particolare, restare in famiglia è quasi sempre meno rischioso che cambiare framework mentre si cambia versione del linguaggio.

Il caso più impegnativo che ho portato a termine è l'upgrade di una codebase da PHP 5.3 con Symfony 3 fino a PHP 8.5 con Symfony 7. Non è un salto che si fa in un passaggio solo: si attraversano più major, e ognuna porta con sé rimozioni e cambi di comportamento che il codice esistente non conosce.

L'ho affrontato con Rector per le trasformazioni automatiche del codice, che copre in modo affidabile la parte meccanica dell'aggiornamento, e con PHPUnit per i test unitari configurati in modo da far emergere i deprecation warning. Quest'ultimo punto è la parte che rende praticabile l'operazione: i warning di deprecazione diventano un segnale automatico durante il passaggio da una major all'altra, invece di trasformarsi in errori scoperti in produzione mesi dopo.

Il risultato di una migrazione fatta così non è solo una versione più recente: è una codebase che torna ad avere aggiornamenti di sicurezza disponibili e una base di test su cui è possibile continuare a lavorare.

WordPress tendo a non farlo. Non è il terreno su cui do il meglio e preferisco dirlo prima, invece di accettare il lavoro e consegnarlo controvoglia.

Se un progetto lo richiede davvero e il resto dell'intervento ha senso, ci lavoro. Ma se il cuore della richiesta è un sito WordPress, con ogni probabilità esiste qualcuno più adatto di me, e te lo dico in fase di primo contatto.