“A Philosophy of Software Design” di John Ousterhout

“A Philosophy of Software Design” è un testo relativamente breve ma dal contenuto prezioso

Il libro che chiunque intenda lavorare in ambito tecnologico dovrebbe leggere

“A Philosophy of Software Design” di John Ousterhout è una piccola pietra preziosa: difficile da scovare, relativamente poco famoso, non pubblicizzato.

Ma il suo contenuto, condensato in appena 190 pagine, è in grado di cambiare la traiettoria di una carriera.

Iniziamo con il dire che il testo è pervaso dalla prima all’ultima pagina di un incredibile understatement.

L’autore, John Ousterhout, che vanta tra le altre cose:

• Laurea in fisica a Yale.
• Dottorato in Informatica presso l’UCM.
• Invenzione del linguaggio di scripting TCL.
• Creazione del software VLSI CAD MAGIC.
• Creatore del file system LFS (Log- Structured).
• Professore di informatica in istituzioni quali Berkeley e Stanford.

Si presenta però così:

“[…] you might be wondering: what makes me think I know all the answers about software design? To be honest, I don’t.”

Inoltre, non menziona mai il suo incredibile vissuto in nessuna sezione del testo.

Anzi, quando parla in prima persona lo fa in modo quasi ironico, per esempio raccontando di aver passato oltre sei mesi a risolvere un bug che poi era stato causato da una variabile con un nome errato.

Forse queste premesse hanno reso questo testo meno commerciale e per questo ancora più apprezzabile una volta scoperto.

A Philosophy of Software Design: i pilastri

Il libro parte proprio dalla premessa di un corso di Computer Science che l’autore e professore tiene presso l’università di Stanford.

Si tratta quindi di materiale che attinge all’eccellenza della formazione in ambito tecnologico.

Questo unito all’esperienza sul campo di Ousterhout, che ha alle spalle 20 anni di attività come sviluppatore.

Complexity

“A Philosophy of Software Design” dedica ampio spazio a trattare il tema della complessità.

Secondo l’autore la complessità è definibile come:

• Change Amplification: qualcosa che per essere modificato anche in una sua piccola parte richiede di modificare molti altri componenti.
• Cognitive Load: qualcosa che per essere gestito o compreso richiede di immagazzinare un gran numero di informazioni.
• Unknown Unknowns: non è ovvio o semplice individuare cosa occorra modificare per apportare un cambiamento ad uno stato o a un oggetto.

Secondo l’autore, il codice deve essere “semplice da leggere” come risultato finale.

Questo a discapito di altri eventuali elementi. Pertanto è perfettamente accettabile che un programma sia “complesso da scrivere, purché semplice da leggere”.

La complessità va gestita alla fonte, il prima possibile, e non fatta ricadere layer dopo layer sull’utilizzatore finale del codice.

Deep Modules

Tema centrale dell’intera opera.

“A Philosophy of Software Design” sostiene fermamente che i moduli debbano essere profondi.

Ossia, la loro implementazione deve essere molto densa e racchiudere un gran numero di specifiche, contrapponendosi a invece interfacce semplici, elementari.

Curiosamente questo va in netto contrasto con i suggerimenti canonici del software design, che invece suggeriscono di avere classi e metodi di piccole dimensioni, quasi atomici (uno su tutti: “Clean Code“).

L’autore fa anche diversi esempi a supporto di ogni sezione, esplicitando con parti di codice, principalmente Java e C.

Design instead than writing code

John Ousterhout conia l’espressione “design it twice”, evidenziando come a suo avviso sia necessario affrontare il problema prima di tutto dal punto di vista del design, esplorando diverse soluzioni, e solo dopo scrivere codice.

In tal senso, sempre riportando il pensiero dell’autore, anche gli stessi design pattern possono essere cattivi maestri in quanto bloccano il pensiero evitando di esplorare soluzioni potenzialmente migliori.

Secondo l’autore la parte dove lo sviluppatore può dare valore non è tanto la mera scrittura del codice, ma il design dell’applicativo, dell’architettura.

A Philosophy of Software Design: i comandamenti

Il testo può essere riassunto nei seguenti punti, che l’autore stesso pone come epilogo dell’intero manuale:

• Complexity is incremental; you have to start from the small stuff
• Working code is not enough.
• Make continual small investments to improve system design.
• Modules should be deep.
• Interfaces should be made to make the most common usage as simple as possible.
• It’s more important for modules to have a simpler interface than a simpler implementation.
• General purpose modules are deeper.
• Separate general-purpose and special-purpose code.
• Different layers should have different abstractions.
• Pull complexity downward.
• Define errors and special cases out of existence.
• Design it twice.
• Comments should describe things that are non-obvious from the code itself.
• Software should be designed for ease of reading not ease of writing.
• The increment of software development should be abstractions not features.

A Philosophy of Software Design: i punti deboli

Lungi dal voler confutare il parere di un luminare ma va detto che alcuni capitoli sono quanto meno degni di essere affrontati con spirito critico.

In particolare:

• I commenti. Secondo l’autore, ogni singolo elemento del codice deve essere commentato. Questo capitolo è uno dei più densi dell’intera opera e va in contrasto con diversi principi del design, tra i quali Uncle Bob. Il tema mi ha appassionato e ne ho parlato anche su Linkedin.
• Best practice. Lo spazio che il testo dedica al testing è molto ridotto, lo spazio dedicato alla documentazione è scarno, tutto quanto riguardi la sicurezza (oltre che le performance, che invece è tema ampiamente trattato) è assente. Una scelta forse curiosa, forse dettata dalla volontà di tenere il testo sotto le 200 pagine.
• Challenge. L’autore sceglie esempi che suffragano le sue idee e concetti. Mi sarebbe piaciuto trovare anche qualche punto di vista alternativo, magari da smontare riga per riga per apprezzare la differenza di approccio e risultati.

Un libro da avere?

Secondo me sì. Una lettura rapida, pregna di significato, e anche un po’ diversa dai soliti approcci altisonanti che troppo spesso offuscano la materia.

L’autore

John Kenneth Ousterhout è professore di informatica all’Università di Stanford.

Ha fondato Electric Cloud con John Graham-Cumming.

Ousterhout è stato professore di informatica all’Università della California, Berkeley, dove ha creato il linguaggio di scripting Tcl e il toolkit per widget indipendenti dalla piattaforma Tk.

Ousterhout ha guidato il gruppo di ricerca che ha progettato il sistema operativo sperimentale Sprite e il primo file system strutturato in log.

Ha anche guidato il team che ha sviluppato il programma di progettazione assistita da computer (CAD) Magic VLSI.

L’autore ha conseguito la laurea in fisica presso l’Università di Yale nel 1975 e il dottorato in informatica presso la Carnegie Mellon University nel 1980.

Nel 1987 Ousterhout ha ricevuto il Grace Murray Hopper Award per il suo lavoro sui sistemi CAD di automazione della progettazione elettronica per circuiti integrati su larghissima scala. Per lo stesso lavoro, nel 1994 è stato nominato Fellow dell’Association for Computing Machinery. Ousterhout è stato eletto membro della National Academy of Engineering nel 2001.

In cerca di ispirazione?

Leggi tutte le nostre recensioni!