Perché Uncle Bob
Robert Cecil Martin è soprannominato Uncle Bob, zio Bob, da bravo decano della buona programmazione e del buon codice e – si immagina – per la sua numerosa progenie: come ebbe a dire in una intervista a DZone,
ho quattro figli e 5,75 nipoti.
Nel mondo anglosassone c’è anche un modo di dire che recita Bob’s your uncle, Bob è tuo zio, per dire è tutto ok. Viene dal XIX secolo, quando il primo ministro inglese Lord Robert Stanley nominò suo nipote Cancelliere dello Scacchiere.
Nel tempo la frase ha perso il carattere sarcastico iniziale e oggi la si usa, appunto, a significare che tutto è sistemato. In questo senso, Uncle Bob è anche qualcuno che mette a posto le cose.
Mezzo secolo di carriera
Nato nel 1952 (il 5 dicembre), Uncle Bob ha scoperto la programmazione a dodici anni. Oggi continua a lavorare dal sito Cleancoder.com e a proporre i suoi principî e insegnamenti tramite il sito Clean Coders.
Tiene conferenze e corsi e ha scritto nel tempo libri che sono pilastri della buona programmazione, come Clean Code, Clean Architecture, Clean Agile e Clean Craftsmanship.
Qualche contributo di Uncle Bob
Le tre regole del Test Driven Development
- Non hai il permesso di scrivere codice di produzione a meno che serva per fare passare un test a uno unit test che lo fallisce.
- Non hai il permesso di scrivere uno unit più di quanto sia sufficiente a farlo fallire; e i fallimenti in compilazione sono fallimenti.
- Non hai il permesso di scrivere più codice di produzione di quanto sia sufficiente per passare uno unit test.
Il Manifesto per lo Sviluppo Agile di Software
Uncle Bob è stato tra i diciassette firmatari del Manifesto originale, disponibile gratuitamente in edizione italiana.
Leggi anche: I quattro valori di Agile, di Robert C. Uncle Bob Martin
I principî SOLID della programmazione a oggetti
Alcuni degli insegnamenti di Uncle Bob si riassumono nell’acronimo SOLID, che sta per Single-responsibility, Open-closed, Liskov substitution, Interface segregation e Dependency Inversion. Ecco una loro definizione:
Single-responsibility. Una classe dovrebbe avere una e solo una ragione per cambiare, nel senso che dovrebbe svolgere un unico lavoro.
Open-closed. Oggetti o entità dovrebbero essere aperti alle estensioni e chiusi alle modifiche.
Liskov substitution. Supponiamo che q(x) sia una proprietà dimostrabile degli oggetti di x di tipo T. In questo caso, q(y) dovrebbe essere dimostrabile per oggetti y di tipo S dove S è un sottotipo di T. Più semplicemente, ogni sottoclasse o classe derivata dovrebbe essere sostituibile dalla classe base o genitrice.
Interface segregation. Un client non dovrebbe mai essere forzato a implementare un’interfaccia che non usa, o i client non dovrebbero essere forzati a dipendere da metodi che non usano.
Dependency inversion. Le entità devono dipendere da astrazioni, non da concrezioni. Un modulo di alto livello non deve dipendere da un modulo di basso livello, ma entrambi dovrebbero dipendere da una astrazione.
Che linguaggi usa Uncle Bob
- Java, perché è comune e dispone di un sacco di strumenti.
- Clojure, perché è potente, elegante, bello e cavalca la Java Virtual Machine.
- Go, perché è veloce, veloce e ancora veloce, il successore logico di C e C++.
- Python, perché è comune e facile.
- Ruby, perché è comune, ricco e pieno di dettagli intriganti.
Una frase storica
Abbiamo scelto la strategia peggiore per andare veloci. Non si va veloci facendo in fretta. Si va veloci facendo un buon lavoro con attenzione.
Uncle Bob su Apogeonline
Per approfondire le tematiche care a Robert Martin, puoi leggere articoli ed estratti dai suoi libri:
- Clean Code: avvertenze ed euristiche
- Clean Code: l’importanza del codice agile e pulito
- La Clean Architecture la si capisce in cinquant’anni
- I quattro valori di Agile
- 5 risposte su… organizzare una programmazione Agile davvero Clean
- 5 risposte su… Clean Craftsmanship: diventare maestri dello sviluppo software
- Clean Craftsmanship: le doti di uno sviluppatore coraggioso
Uncle Bob in azione
Questo video è uno dei più recenti disponibili pubblicamente e mostra Robert Martin assieme a Allen Holub in una conferenza dal titolo A Path to Better Programming.