Ultimamente ho dovuto affontare uno di questi problemi: in YouRank abbiamo una definizione di domain che consente data un’url di ricavare quello che noi consideriamo essere il dominio di quell’url. Quello che facciamo è eliminare il protocollo, generalmente “http://” e la parte iniziale dell’url se e solo se questa corrisponde a “[wW]{3}[^.]+\.”. Quindi l’url “http://www.gabrielelana.it” avrebbe come identificativo di dominio “gabrielelana.it”

Questo tipo di operazione (estrazione dell’identificativo univoco del dominio di un’url) deve essere eseguita in contesti differenti: sia durante l’elaborazione dei dati di navigazione grezzi (quindi in javascript), sia durante l’esecuzione di query sul database (banalmente per raggruppare i risultati per dominio). Inizialmente, proprio per evitare di duplicare il codice, ho optato per un’implementazione in javascript “yr.uri.Http#domainWithoutPrefix” (metodo domainWithoutPrefix della classe yr.uri.Http), che richiamavo all’interno delle query di sqlite “JS_CALL(“DOMAIN_WITHOUT_PREFIX”, urlOfDomain)” [1], per ogni record del result set dovevo creare un oggetto “yr.uri.Http” solo per poter utilizzare il metodo “domainWithoutPrefix, questo unito al costo del marshalling fra sqlite e javascript, si è rivelato essere superiore al budget :-)

I miei sensi di ragno mi facevano venire la nausea tutte le volte che pensavo all’ovvia soluzione del problema: implementare in C la funzione “DOMAIN_WITHOUT_PREFIX” da richiamare direttamente in sqlite. Ho passato giorni a tentare di immaginarmi soluzioni alternative al problema senza trovare niente. Alla fine ho mollato, ho iniziato a scrivere il primo test automatico e subito ho capito

Stavo sostanzialmente riscrivendo i test che a suo tempo scrissi per “yr.uri.Http#domainWithoutPrefix”, questo si che sarebbe stato veramente sbagliato! Potevo ancora conservare in un’unico punto autorevole la definizione del concetto di identificato di dominio: nei test. In pseudo codice

assertDomainWithoutPrefixIs("gabrielelana.it", "http://www.gabrielelana.it")
assertDomainWithoutPrefixIs("blog.yourank.com", "http://blog.yourank.com")
assertDomainWithoutPrefixIs("example.com", "http://www1.example.com")
assertDomainWithoutPrefixIs("example.com", "http://www123.example.com")
assertDomainWithoutPrefixIs("w12.example.com", "http://w12.example.com")
...

dove

assertDomainWithoutPrefixIs = function(expected, given) {
    assertEquals(expected, storage.call("DOMAIN_WITHOUT_PREFIX", given));
    assertEquals(expected, yr.uri.Http(given).domainWithoutPrefix);
}

Quindi, la lezione che ho imparato è: “Se non è possibile mantenere la definizione di un concetto in un unico punto all’interno del codice, testa tutte le implementazioni esistenti con un unico test automatico, in modo da far diventare il test quell’unico punto”

Link of the week
Quote of the week

No problem. “Easy” in the developer sense, of course, which translates in real life to “theoretically possible and I have a vague plan”

[1] Abbiamo implementato un meccanismo attraverso il quale è possibile invocare delle funzioni javascript (previo setup) da delle query sqlite, niente di esoterico (anche il wrapper a sqlite di mozilla implementa lo stesso meccanismo) solo una precisazione nel caso qualcuno se lo fosse chiesto

“Cos’è, e come viene usato il refatoring?” Dato il codice di un’applicazione e conoscendo la prossima funzionalità che dovrà essere implementata, posso domandarmi “Il Design della mia applicazione è adatto ad accogliere l’implementazione della prossima funzionalità? Con la conoscenza che ho oggi della mia applicazione e del dominio del problema, posso migliorarne il Design?” Rispondendo a queste domande identifico il Design che vorrei che la mia applicazione avesse e grazie al refactoring, sarò in grado di pianificare in piccoli passi il passaggio dal Design attuale a quello ideale, dopodichè sarò pronto ad implementare la funzionalità richiesta. Applicando il TDD questo ciclo (requirement/design/refactoring/test/coding/) diventa molto più frequente (da pochi minuti a pochi secondi), ma il discorso non cambia.

Non so se avete notato, ma per applicare questa pratica è necessario:

• Saper identificare il Design attuale leggendo il codice
• Saper individuare, non solo i bad smell banali quali il “Long Method” o “Large Class”, ma anche quelli per cui occorre una visione più ad alto livello dell’applicazione, come: “Speculative Generality”, “Divergent Change”, “Shotgun Surgery”, ecc…
• Saper indicare quale Design migliorerebbe quello attuale

Ovvero è necessario:

• Conoscere il Design del software: pattern, principi, idiomi ecc… (alcuni strettamente dipendenti dal linguaggio utilizzato)
• Imparare a leggere il codice sorgente di un’applicazione. Qualcuno potrebbe darlo per scontato, ma non lo è. Pensate agli scrittori di libri e a quanto mediamente leggono: leggono per imparare, leggono per farsi ispirare, leggono per poter trovare la propria identità letteraria come fusione fra gli stili appresi e la propria personalità. Voi quanto buon codice leggete?
• Conoscere e saper identificare i bad smell
• Conoscere e saper applicare i passi di refactoring per poterli eliminare

Tutto questo per dire che l’applicazione della sola pratica del refactoring non giustifica in alcun modo un’ignoranza nel campo del Design del software. Il refactoring è solo una tecnica che ci permette di raggiungere un determinato Design in maniera incrementale, requisito dopo requisito, in modo da avere in ogni momento il miglior Design possibile per le funzionalità attualmente implementate. In pratica il design di oggi è frutto di un BDUF dilazionato durante tutto il progetto, ma la parte di design Design c’è, e deve essere studiata!

Vedo già qualcuno che salta in piedi dicendo “Allora è vero, solo i programmatori preparati possono applicare le metodologie Agili!” A questa frase replico con un estratto da questo intervento di Ken Schwaber

SCRUM works with idiots. You can take a group of idiots tha maybe even didn’t go to school, don’t understand computer science, don’t understand software, engineering techniques, hate each other, don’t understand business domain, have lousy engineering tools and uniformly they will produce crap every increment

UPDATE: Neanche a farlo apposta, oggi (18/07/2007) su InfoQ Amr Elssamadisy ha espresso le stesse perplessità, James Shore ha subito replicato