Archivi categoria: software design

Il design è un’attività continua, non solo una fase

Nell’approccio a cascata, il design è una fase (periodo di lavoro) distinta, con un inizio e una fine definiti e criteri di ingresso e uscita specificati.

Il design visto come fase (cioè periodo delimitato nel tempo) era adeguato alla produzione industriale tradizionale, e ad altri settori come l’edilizia. Ora è meno adeguato, in quanto gli utenti (consumatori, clienti) stanno diventando sempre più esigenti e impongono ai propri fornitori un miglioramento continuo.

The world that digital technology creates is highly complex and ever-changing. There is rarely now a simple and clear-cut design phase, followed by an installation or rollout phase. The system being designed has become fluid. It needs to be constantly optimized and refined. The interface must be constantly evolving based on customer feedback. In this sort of world, design becomes a constant process and a way of thinking.

Come scrive Gerry McGovern in Design has become a continuous activity, le organizzazioni sono costrette ad adeguarsi alla crescente maturità dei propri clienti, ad ascoltarli e a migliorare continuamente il design del proprio prodotto o servizio.

Nomi adeguati per le funzioni

Che nomi dare alle funzioni in un programma? Nomi che facciano capire cosa fanno, non il modo in cui lo fanno.

Separare l’obiettivo dall’implementazione, come spiega Fowler in Function Length.

Il nome deve spiegare immediatamente cosa si vuole ottenere con la funzione (l’intenzione), senza dover mettere il naso negli statement che la implementano. Anche quando l’implementazione consiste in un unico statement.

I remember people objecting to having an isEmpty method for a list when the common idiom is to use aList.length == 0. But here using the intention-revealing name on a function may also support better performance if it’s faster to figure out if a collection is empty than to determine its length.

Test Driven Development: indispensabile?

Nelle ultime settimane si è sviluppata una discussione in merito al Test Driven Development (sviluppo guidato dai test, una pratica che prevede la scrittura dei test prima della scrittura del codice necessario a superarli).

Iniziata con un intervento di David Heinemeier Hansson, l’ideatore di Ruby on Rails, la discussione sta coinvolgendo alcuni tra i migliori esperti di software design, come Robert Martin, Kent Beck e Martin Fowler. Tra Heinemeier Hansson, Beck e Fowler sono in corso dialoghi interessanti: uno , due , tre (e successivi).

Design (e software design)

Una conferenza in italiano di Paola Antonelli, responsabile ricerca e sviluppo del MOMA, il museo di arte contemporanea di New York.

Spunti interessanti anche sulla visualizzazione delle informazioni, sul design delle interazioni, sui videogame e più in generale sul ruolo del design digitale.

La conferenza si è svolta a Milano, nell’ambito di Meet the Media Guru,  il 10 aprile 2014 (i primi 15 minuti di interventi introduttivi si possono evitare).