Sviluppare applicazioni con PHP e MySQL / 2

Abbiamo iniziato l’intervista a Tom Butler, coautore di Sviluppare applicazioni con PHP e MySQL, lo scorso 12 febbraio e continuiamo oggi a presentare il suo pensiero riguardante il libro, lo sviluppo con PHP e MySQL e i database.

Apogeonline: Da quando sono nati PHP e MySQL, gli ambiti mobile sono diventati preminenti. Come è cambiata negli anni la programmazione in risposta alle applicazioni web mobile-ready?

Tom Butler: Essendo PHP un linguaggio lato server, non viene influenzato molto dagli apparecchi tascabili. Il server web non ha interesse a sapere se il client è un computer da scrivania o da polso. La differenza riguarda soprattutto lo sviluppo a livello di client. Le app mobile e le tecniche di sviluppo hanno aumentato l’impiego di Ajax e JSON, ma sono tecnologie diffuse da ben prima. PHP è comunque cambiato molto da allora. Sia il linguaggio che che gli sviluppatori hanno preso la programmazione orientata agli oggetti molto più seriamente e questo si vede nella maggior parte dei progetti di qualità. La tendenza attuale va verso la scrittura di classi che possano essere condivise e riutilizzate su progetti differenti. Pongo molta attenzione sulla programmazione a oggetti nel libro e chi arriva alla fine si ritrova ad avere scritto dentro classi praticamente tutto il codice, o quasi.

A che tipo di lettore pensavi mentre concepivi il tuo libro? E a che tipo di lettura? Sequenziale o più come documentazione, materiale di riferimento?

Il titolo originale del libro è Da novizio a ninja, a dire che avevo in mente lo sviluppatore agli inizi. Si può cominciare la lettura senza avere mai scritto prima una riga di codice. Sarebbe meglio la conoscenza preventiva di un poco di HTML e CSS, ma neanche questa è realmente indispensabile. In molte aziende c’è una separazione tra ruoli di sviluppo di front end (HTML/CSS) e back end (lato server) e il libro contiene tutto quello che serve quanto a HTML e CSS. Ho scritto pensando a una lettura sequenziale. Una delle prime cose che dico ai miei studenti è ricordarsi di come i concetti della programmazione poggino uno sull’altro, per cui tentare di saltare una sezione usualmente complica l’apprendimento.

Da novizio a ninja della programmazione web.

Nel libro accompagno il lettore mediante un esempio piuttosto semplice che passo dopo passo diventa un sito moderno e funzionale. Questo approccio fa sì che sia facile vedere capitolo per capitolo che cosa viene introdotto di nuovo. Contemporaneamente, saltare un segmento del libro fa perdere una parte della costruzione del sito. Più avanti, comprendere ciò che succede diventerà più difficile. Uno dei miei obiettivi al momento di scrivere il libro era spiegare il perché delle cose, oltre al come. Pagina dopo pagina analizzo i pro e i contro di approcci diversi nonché le riflessioni che stanno dietro l’uso di uno o un altro strumento. Lo sviluppo del codice procede gradualmente ma ci si troverà ugualmente a tornare indietro di tanto in tanto per rinfrescare la conoscenza del perché le cose vanno nel modo che mostro nel libro.

Qual è il miglior capitolo del libro e perché?

Il mio capitolo preferito è quello sulle relazioni. Mostro come funziona la programmazione a oggetti con esempi veri e non le solite banalità su dipendenti e dirigenti o gatti e animali. A quel punto del libro, il lettore sta usando programmazione a oggetti ovunque e conosce la differenza tra classi riusabili o per progetti specifici. Può quindi prendere le classi del framework e costruirci più o meno qualsiasi sito gli venga in mente.

È facile leggere di programmazione in rete, un po’ meno di database relazionali. Ritengo importante avere una sezione dedicata nel libro. Perché non va sottovalutato un buon design del database?

C’è meno informazione sui database perché è molto più difficile progettarne uno male, di quanto non sia pasticciare con il codice PHP. Ci sono certo regole da seguire (evitare duplicazioni, avere gli indici al posto giusto) ma è difficile lavorare così male che ogni ulteriore sviluppo del database richieda una riprogettazione. Al contrario, se il codice è male progettato, diventa difficile o impossibile usarlo come base di sviluppo e si finisce per riscrivere tutto.. La nozione di buon design di database è inoltre soggettiva. I programmatori focalizzati sulla programmazione a oggetti, come me, preferiscono tenere il database più semplice e irrilevante possibile. Più lavoro svolge il database, più è difficile sostituirlo per i test. Se il database è pieno di vincoli, trigger, cancellazioni a cascata e procedure memorizzate, i collaudi diventano impegnativi. Se invece il database può essere sostituito da json_decode, il programma è significativamente più flessibile e semplice da mettere alla prova.