phpday è l’evento italiano interamente dedicato al linguaggio di programmazione php. quest’anno si è tenuto a verona il 15 e 16 maggio. diviso in tre canali, developers, enterprise e community il convegno punta alla diffusione di questo linguaggio, non solo ad un utilizzo amatoriale, ma sempre più verso importanti applicazioni di tipo enterprise.

evento ricco di spunti di riflessione e di contenuti rilevanti: è stato molto interessante l’intervento di francesco fullone che ci ha spiegato che la semplicità del php spesso viene percepita come qualcosa di “non professionale” e da relegare al solo mondo degli smanettoni. ma non è così: ciò che rende un’applicazione enterprise non è il linguaggio bensì i metodi ed i pattern con cui essa viene sviluppata e testata. è questo il principale messaggio che il phpday ha voluto far emergere in questa edizione: a fare la differenza è la competenza e la professionalità di chi sviluppa, non il linguaggio, ma le persone.

un altro concetto chiave è stato lo “spaghetti code refactoring“, ossia la refattorizzare del codice vecchio, scritto male o non più mantenibile, invece che riscrivere completamente l’applicazione che si basa su di esso. ma perchè “complicarsi” la vita con del codice talmente intricato, che somiglia proprio ad un piatto di spaghetti ?

la risposta che francesco trucchia da nel suo workshop è molto semplice: l’utente non ragiona come uno sviluppatore! l’utente si “affeziona” a funzionalità ed interfacce che il programmatore inevitabilmente non può prevedere. anche il semplice accostamento di due funzionalità nella stessa form, spesso assolutamente casuale, potrebbe far parte di un meccanismo non esplicitato che con una completa riscrittura dell’applicazione si andrebbe a perdere.

meccanismo che il programmatore in questione percepisce come superfluo (o non percepisce affatto) ma che l’utente vive come un vero e proprio valore aggiunto. riscrivere l’applicazione da zero potrebbe far perdere questo valore aggiunto, facendo paradossalmente peggiorare il feedback verso la nuova applicazione, sicuramente bellissima e perfetta, ma che non segue più i desideri del nostro cliente.

il refactoring è un vero e proprio restauro, una pratica da vivere come un’arte nell’arte: l’artista con la propria opera, il restauratore con il proprio restauro, ed ogni opera è unica. l’interessantissimo intervento di trucchia ci spiega tutto questo attraverso le pratiche del KISS, DRY e TDD utilizzando un approccio DDD con design pattern.

eccole in dettaglio:

- keep it simple, stupid (KISS) significa che tutto ciò che si fa, va fatto nel modo più semplice (e stupido!)  possibile, senza complicare la situazione con ipotesi o ottimizzazioni aggiuntive che non sono ancora state esplicitate. è più semplice sviluppare in questo modo, come lo sarà poter testare il proprio lavoro. è soprattutto più semplice poter aggiungere funzionalità in un secondo momento, refattorizzando il codice. KISS evita sin da subito gli spaghetti.

- test driven development (TDD) tutto deve passare per un test. è una pratica che non punta alla correzione dei bug, ma tende al non averne affatto. i bug non sono prevedibili ed il debug è solo un costo e per i nostri clienti è solo un difetto. come quantificarne poi l’entità? sviluppare dei test automatici che andranno a guidare lo sviluppo dell’applicazione è un investimento ed ha un ROI: debug minimo e maggior semplicità di aggiungere nuove features senza compromettere le precedenti, soprattutto si passa da una variabile casuale (nr° di bug da correggere) ad una deterministica (sviluppo dei test).

- don’t repeat yourself (DRY) se qualcosa ha la necessità di essere ripetuto, significa che si deve eseguire un “extract method”: creare una funzionalità, magari privata, per risolvere quel problema e richiamarla nell’applicazione, ove è richiesta. non si deve ripetere codice in punti diversi: se un giorno la funzionalità avrà la necessità di essere rivista, basterà un intervento nel singolo punto in cui è definita, viceversa dovremmo cambiare tutte le porzioni di codice in cui è stata ripetuta: siamo esseri umani e sicuramente da qualche parte tralasceremmo qualcosa.

- domain driven design (DDD) bruttissimo vizio diffuso tra gli sviluppatori è inventare nomi di metodi e variabili basati su acronimi o tecnicismi che il cliente non percepisce e la comunicazione diventa difficile. è bene usare lo stesso linguaggio del cliente! è meglio seguire il suo dominio e dove si hanno ambiguità risolverle a priori, concordandole. il codice sarà leggibile e sarà molto più semplice intervenire su di esso, in base al feedback ricevuto. il cliente parla la propria lingua, non il nostro linguaggio di programmazione.

- design pattern un design pattern non è un algoritmo bensì un vero e proprio modello da applicare in presenza di un problema. è la descrizione ottimale al raggiungimento di una soluzione, in presenza di un determinato problema ed i contesti tipici in cui si trova. in poche parole: soluzioni simili a problemi simili.

il phpday2009 è stato molto utile e si è confermato anche quest’anno un punto di riferimento per gli sviluppatori italiani. un’occasione per mettere in discussione le proprie metodologie e per  condividere le soluzioni web sviluppate: è sempre costruttivo lo scambio di idee con esperti del settore e il confronto riguardo problemi incontrati in comune.

michele e giorgio

Archiviato in: eventi | Tags: phpday2009 | Non ci sono commenti