Su quali criteri sceglierei o non sceglierei un framework PHP per il mio prossimo progetto web?

Nei 15 anni abbondanti spesi nella mia professione di sviluppatore web in libera professione, ho usato molte diverse tecnologie per costruire le più disparate piattaforme, dal semplice sito web al grosso e-commerce B2C o B2B, per arrivare alle piattaforme personalizzate cucite sulle esigenze del cliente. 

E devo dire che di framework e CMS PHP, negli anni, ne ho usati parecchi, e là fuori ce ne è altrettanti che non ho mai avuto il piacere di provare, sebbene li conosca per fama. Dai conosciutissimi e super utilizzati Symfony e Laravel, fino ai meno blasonati CodeIgniter, Yii, CakePHP e altri, ognuno con i suoi pro e i suoi contro.

Devo dire che nella mia lista dei motivi per cui sceglierei, o non sceglierei, un determinato framework php oggi, ce ne sono un paio che a parer mio non sempre vengono sufficientemente considerati.

Se partiamo dal presupposto che ormai tutti, o quasi tutti, i framework là fuori garantiscono moderni approcci alla programmazione (MVC, ORM, etc), permettono di scrivere codice pulito, sicuro e con tempi di sviluppo enormemente ridotti rispetto al “re-inventare la ruota” partendo dal puro e semplice codice PHP, su quali criteri dovrei basarmi per sceglierne uno?

Io personalmente valuterei prima di tutto i seguenti due aspetti. Eccoli:

1) i tempi nel rilascio delle nuove versioni del framework (“ciclo di rilascio”)e i relativi tempi di supporto delle versioni precedenti e

2) la perdita in termini di prestazioni che l’adottare tale framework comporterebbe

Prima di entrare nel dettaglio dei suddetti criteri, è ovvio che sarà necessario valutare altri pro e contro, e che ognuno di noi avrà le proprie personali idiosincrasie ad usare questa o quella tecnologia, le proprie esperienze personali, si sarà fatto delle idee leggendo in rete e nei blog o nelle varie documentazioni online, e potrebbe quindi avere criteri di scelta completamente rovesciati rispetto ai nostri qui a LabortatorioLibero. Non è banale aggiungere poi che spesso “il nostro cuore batte per quella particolare tecnologia”, per cui le scelte che faremo potrebbero essere dettate più da fattori emotivi che da fattori razionali, e anche questo, detto francamente, ci può stare!

Fatte le dovute premesse, ecco perché secondo me i due criteri di scelta indicati sopra sono i più importanti quando si deve valutare quale framework utilizzare per il nostro nuovo progetto web.

Relativamente al primo punto, le tempistiche di rilascio di nuove versioni del framework, spesso tali tempistiche di rilascio sono troppo frequenti al punto di “non essere compatibili con i tempi del mondo del lavoro”, soprattutto nel caso di quei progetti web (siti o e-commerce che siano) che hanno una vita molto molto lunga. Per mia esperienza personale, anche dieci anni o più.

Considerando che alcuni framework fanno uscire una nuova release ogni 6 mesi (!) o ogni anno, introducendo di volta in volta un lungo elenco di funzioni deprecate, se non addirittura grosse modifiche al flusso logico, che costringono una pesante riscrittura del proprio codice, il fattore “tempi di rilascio” non è affatto da sottovalutare.

È vero che l’aggiornamento è fondamentale per ogni software o framework che si rispetti, soprattutto in un mondo così dinamico come quello dello sviluppo web e del web in generale, ma a ben guardare una propensione alla riscrittura così frequente sembra richiamare più un atteggiamento universitario che non un atteggiamento legato al mondo del lavoro, dove l’attenzione non è posta sulla stabilità, ma sulla ricerca del "lessico informatico perfetto".

Alcuni dei nostri progetti più grossi hanno avuto un tempo di sviluppo più lungo del tempo di rilascio di alcuni framework! In quel caso saremmo partiti con una versione del suddetto framework per ritrovarci, a lavori finiti, magari 8 mesi dopo, con il nostro codice già obsoleto (!) perché nel frattempo era uscita la release successiva del framework! Certo, sono casistiche al limite, ma assolutamente da non sottovalutare!

È vero che poi l’aggiornamento viene addebitato al cliente alla voce “costi di assistenza e aggiornamento annuale”, ma è anche vero che, dal punto di vista di un’azienda di sviluppo software, questo continuo lavorio di aggiornamento può risultare “snervante” e nel mondo ideale ogni azienda sogna (almeno per noi è così) di mettere online una piattaforma che non richiederà nel tempo niente altro che ridottissimi interventi di aggiornamento.

Soprattutto nei progetti più grandi, come grossi e-commerce o aree riservate corpose e molto utilizzate, continue modifiche al codice significano il rischio di introdurre errori anche “costosi”, cosa che non piace proprio a nessuno. E se si decide di ignorare gli aggiornamenti semestrali o annuali si corre il rischio di ritrovarsi in pochi anni con una versione del codice così obsoleta che l’aggiornamento diventa quasi paragonabile ad una riscrittura completa!

Potrebbe anche essere una strategia commerciale, non lo nego, ma nel nostro caso la strategia migliore, commerciale e tecnica, è quella di mettere online qualcosa di stabile nel tempo, sia per il cliente... che per noi!

Anche il secondo criterio di scelta del framework, la perdita in termini di prestazioni, non è affatto da sottovalutare. Spesso, con la smania di utilizzare il framework all’ultimo grido, o quello con la maggior semplicità di utilizzo, o quello che usano tutti (!), finiamo per adottare un pesante e monolitico “carrozzone” capace sì di velocizzare di molto i tempi di sviluppo, ma che finisce poi per azzoppare il sito web (o l’ecommerce) in termini di tempi di esecuzione e carico sul server.. anche di un ordine di grandezza!

È ovvio che ogni framework che si rispetti deve garantire tutta quella serie di funzionalità atte a risolvere problemi comuni nel mondo dello sviluppo web, ma questo non deve andare troppo a scapito della velocità di esecuzione. L’ideale sarebbe un framework che permetta di attivare solo le funzionalità che davvero servono al nostro progetto, lasciando le altre nel cassetto. 

Per questo a volte è meglio scegliere un framework più modulare, più leggero, meno “monolitico”.. cioè che non metta in moto un “transatlantico” in termini di layer intermedi in fase di boot, o un vietnam di query mal scritte, solo per la gestione del più semplice dei siti web.. per poi costringerci ad attivare sistemi di cache anche là dove forse non sarebbero serviti!

Ovvio che la problematica dell’accesso al database è centrale in questa discussione, e da questo punto di vista la scelta di un framework che comprenda un efficiente e chiaro ORM o QueryBuilder, che non utilizzi troppa “magia” per semplificare la gestione dell’accesso al DB con il risultato poi di offuscare le reali query effettuate o che renda facile l’ottimizzazione delle stesse, è sicuramente una scelta vincente. 

Dopo qualche anno di sviluppo si arriva in fretta a capire e/o prevedere quelli che possono essere i colli di bottiglia della propria applicazione e/o del proprio modello di design del software.. fate in modo che il collo di bottiglia non finisca per essere il framework che decidete di usare!!