Gabriele Lana

Ho appena finito di leggere un articolo del venerabile Paul Graham, autore di libri quali “Hackers and Painters” e “On Lisp” (libro da me molto ambito, ma alquanto difficile da avere)

L’articolo indica alcune pratiche che possono essere utilizzate dai programmatori per “mantenere un programma nella propria testa”, inizialmente sia l’obiettivo dell’articolo che alcune delle pratiche proposte mi hanno un po’ disorientato in quanto in apparente netto contrasto con quanto dettato dalle metodologie Agili: “Se Paul Graham è un mito, e ha ragione, allora hanno torto le metodologie Agili?” No, hanno ragione entrambi, i principi che stanno alla base sono gli stessi, come al solito tutto torna :-)

Prendiamo per esempio una delle pratiche più forti fra quelle proposte: “Keep rewriting your program”; come dargli torto? Capita spesso che durante la scrittura di un programma un programmatore arrivi ad un momento in cui la sua conoscenza attuale del problema e della relativa soluzione non sia più rispecchiata dal codice, riscrivendolo potremmo inserire nel codice tale conoscenza e quindi otterremmo del codice migliore. D’altra parte molti conosceranno la “Sindrome del secondo sistema” e sapranno quindi che la maggior parte delle riscritture dei progetti software risulta fallimentare. “Come è possibile che entrambe queste evidenze empiriche siano vere? Come risolvono la questione le metodologie Agili?”

Cos’è il refactoring se non un’attività di continua riscrittura del codice? Kent Beck spiega perchè eXtreme Programming è eXtreme: tutte quelle pratiche che hanno dimostrato nel tempo di essere valide sono state portate all’estremo. La revisione del codice funziona? Bene, revisioniamo il codice sempre! = Pair Programming. La riscrittura di programmi porta a dei programmi con un design migliore? Bene, riscriviamo i nostri programmi continuamente! = Refactoring

Attraverso la pratica del refactoring possiamo trasformare (riscrivere) continuamente il nostro codice affichè rispecchi nella maniera migliore possibile la conoscenza che attualmente abbiamo del dominio del problema e della sua soluzione. Continuamente! Il trucco è sempre quello: se un’attività è rischiosa, difficile, costosa, ma potenzialmente di grande valore, quello che dobbiamo fare non è evitarla o prevenirla, ma trovare un modo per renderla meno rischiosa, meno difficile e meno costosa, mantenendone il valore inalterato (pensate per esempio alla Continuous Integration)

Al solito ci sono pratiche a corollario che portano il codice ad essere rappresentazione della nostra conoscenza:

• Unit Tests: come specifica eseguibile del comportamento dei componenti del nostro software
• Acceptance Tests: come specifica eseguibile delle funzionalità esibite dal nostro software
• Shared Code: fare in modo che il nostro codice sia leggibile a tutti i componenti del team (lo considero un super set di “Write rereadable code” dell’articolo di Graham)
• Domain Driven Design: sviluppare un linguaggio di dominio (Ubiquitous Language) all’interno del codice. Questa pratica potrebbe essere portata all’estremo scrivendo un’interprete per un DSL (Graham come Lisper a questo proposito ne sa qualcosa)