Le conseguenze dell'approccio procedurale in PHP: un'odissea

Ci accorgiamo dei benefici del codice OO solo quando dobbiamo effettuare il redesign di un applicativo interamente procedurale. In questo caso tutti i dibattiti, le discussioni, i punti di vista, le religioni, le ideologie cadono di fronte all'evidenza: è un'odissea. Vediamo perché.

Innanzitutto, il codice PHP che regola il funzionamento dell'applicativo è iniettato in un coagulo di marcatura più o meno valida (non è insolito trovare strutture tabellari pre-CSS) o viceversa. Cià significa che la fatica è doppia: astrarre le routine PHP e la sua logica e rimodellare l'HTML, i CSS e JavaScript.

Quando va bene vengono usate delle funzioni, di solito definite in un file mastodontico con n-mila righe. Quando va male non si usano neppure le funzioni (vedi sopra).

In questo scenario, ovviamente, manca completamente la separazione fondamentale fra PHP e template HTML. Cià porta ad avere un profluvio di file laddove in un contesto MVC la separazione permette di limitare questa proliferazione.

Qui la struttura è assente: non c'è nessun rapporto o relazione tra le parti, se non nella forma di include massivi. Mancando la struttura lo sviluppatore è costretto ad analizzare ogni file cercando di capire il cosa, il come ed il perché di ciascun file.

A livello di produttività  si tratta di un massacro: su applicativi complessi il tempo richiesto per il redesign è notevole. E tutto cià è inaccettabile.

Il problema è che il cliente non sa valutare i pro ed i contro: procedurale od OOP poco importa, basta che funzioni. Salvo poi scoprire cosa succede nel caso specifico dei redesign.

Ma questo lo sa solo lo sviluppatore.