Qualche dettaglio in più sul concorso Pro PHP Refactoring (ed una proroga della scadenza!)

Ciao! Ringraziamo tutti i partecipanti al concorso di refactoring, innanzitutto. Passiamo ai punti salienti di questo post.

1. Nel bando originale avevamo specificato il divieto di utilizzare framework, ma poi autorizzato in comunicati non ufficiali successivi la (più ovvia) possibilità di utilizzare librerie di terze parti. OK, allora il confine tra libreria e framework dov’è? Senza dilungarci qui su un tema che dilania mailing list di tutto il mondo da anni 🙂 basti dire questo: un refactoring graduale dovrebbe garantire da una parte l’emersione di soluzioni efficaci, economiche e libere da vincoli di terze parti, ma è anche vero che un refactoring corretto può portare alla facile installazione di codice di terze parti senza pagare in termini di efficacia e tempo speso. Ribadiamo quindi che il divieto è un divieto morbido: librerie e componenti (c’è davvero differenza?) di terze parti possono essere utlizzate, ma il loro utilizzo sarà uno di quegli aspetti di trade-off valutati dalla giuria: riscrivere da capo l’applicazione proposta in un ambiente nuovo di zecca non sarà certo ritenuto un buon refactoring! Ma usare un front controller di terze parti al momento giusto potrebbe essere un buon modo di ottenere una buona architettura al momento giusto.

2. Un’altra domanda frequente è: ma l’applicazione è la stessa descritta nella parte finale del libro Pro PHP Refactoring? La risposta è sì. A coloro che covassero il dubbio “ma allora il refactoring è già scritto lì, basta copiare?” rispondiamo che

  • il refactoring illustrato nel libro è solo parziale e può essere spinto molto più avanti – se ritenuto necessario
  • il refactoring è un’opinione: divertitevi anche a mettere in discussione il refactoring descritto nel libro

Ogni refactoring è perfettibile. Ogni refactoring può essere sovraingegnerizzazione.

3. I due temi di cui sopra ci portano ad un’inevitabile chiarimento. Se il refactoring è un’opinione ci sono modi oggettivi di decidere il miglior refactoring fra quelli pervenuti? No.
Semplicemente no. Per questo il giudizio della giuria in questi casi viene dichiarato insindacabile. Fa parte del gioco, OK?

4. Per migliorare però la qualità delle revisioni della giuria, si è deciso fosse opportuno considerare anche il percorso di refactoring, la successione delle varie fasi di ristrutturazione. Diventa perciò essenziale per noi chiedervi di appoggiarvi ad un repository GitHub grazie al quale la giuria potrà esplorare la history delle sucessive versioni del vostro codice. Sappiamo che questo potrebbe chiedervi del lavoro extra arrivati a questo punto, ma prima di odiarci considerate che ve lo stiamo chiedendo per valutare meglio il frutto della vostra fatica. Ovviamente, rispettosamente, questo non sarà un requisito obbligatorio: se volete mandarci uno zippone del codice finale fate pure. Però…

5. Tutto quello che abbiamo chiarito o stabilito qui ci impone quindi di rispettare i concorrenti più zelanti e rispettosi delle scadenze e permettere loro di rivedere le proprie scelte di refactoring considerando alcuni dei dettagli emersi. Abbiamo pertanto deciso di prorogare la scadenza del concorso di 2 settimane fino a giovedì 29 dicembre alle 23:59. Inoltre questo permetterà a qualche (a questo punto fortunato) ritardatario di partecipare e a tutti di approfittare della pausa natalizia per concentrarsi sul proprio gioiellino di codice! 😉

È tutto. In bocca al lupo!