Ergonomia nell'industria

Quando ero ancora un ragazzo, oltre alla mia prima passione, l'informatica, mi piaceva l'elettronica, una volta rimasi affascinato da una semplice riflessione sulla maturità del software che lessi in un articolo, l'autore confrontava l'elettronica con lo sviluppo del software, evidenziava come l'industria informatica, pure avendo un grandissimo potenziale, non aveva ancora la maturità tecnologica e produttiva di altre industrie, come quella elettronica... ad esempio adduceva il salto qualitativo e produttivo introdotto dai circuiti integrati.

Ora confrontiamo, presa sempre da wikipedia, la definizione di Ergonomia con gli elementi che ho evidenziato nella precedente di API: "L'ergonomia, secondo la IEA (International Ergonomics Association), è quella scienza che si occupa dell'interazione tra gli elementi di un sistema (umani e d'altro tipo) e la funzione per cui vengono progettati (nonché la teoria, i principi, i dati e i metodi che vengono applicati nella progettazione ), allo scopo di migliorare la soddisfazione dell'utente e l'insieme delle prestazioni del sistema[1]. In pratica è quella scienza che si occupa dello studio dell'interazione tra individui e tecnologie." (Ho evidenziato punti chiave in grassetto)

In effetti in questi anni abbiamo tutti visto un rapido progresso nell'industria delle applicazioni e abbiamo notato come, ad esempio, la "pacchettizzazione" e il deploy del software con metodologie e strumenti più rubusti abbia portato un vantaggio competitivo, in termini di produttività, integrazione e aggiornamento del software. Ma questo è solo un esempio, altre idee importanti ne hanno permesso l'evoluzione qualitativa: i pattern per lo sviluppo di applicazioni (chi non ha letto Patterns of Enterprise Application Architecture? ;)), i linguaggi di programmazione, i compilatori, gli ambienti di sviluppo, le metodologie e gli strumenti agili, il testing unitario e automatico del software (Unit Test e TDD) ...

Ergonomia nel software

Per esperienza ho verificato o sono arrivato alla conclusione che alcune pratiche e metodologie sono strumenti che possono permetterci di modellare l'ergonomia della nostra API. Premetto che ho una mia filosofia sull'utilizzo delle pratiche e metodologie, queste vanno applicate con il giusto equilibrio e nel giusto contesto, sono quindi contrario all'approcio "dogmatico" nell'uso di una pratica, con "dogmatico" intendo un approccio per il quale sembra che una metodologia sia il vaso di pandora che quando la scopro risolverà tutti i miei problemi di sviluppatore e che dovrà essere usata sempre per ogni riga di codice che scrivo ;) ... ho visto nella realtà progetti fallire applicando questa "fuorviante e pericolosa strategia"! Premesso questo di seguito illustro alcune ideo o strumenti che se usati bene sono utili a sviluppare codice "ergonomico" per i nostri programmatori, spiegandone brevemente vantaggi e applicazione puramente nell'ambito di cui si discute in questo thread.

• Naming approach

  Il nome che diamo a una classe o a un metodo, in relazione alla struttura e alla gerarchia di oggetti, soprattuto quando deve essere usato da altri (specialmente quando fa parte del contratto pubblico della nostra API) dovrebbe essere pensato con attenzione. Alcuni programmatori pensano sia una perdita di tempo soffermarsi troppo su quest'aspetto, peccato che poi ci si trova classi e librerie con nomi che seguono una logica disomogenea e a volte fuorvianti che richiedono molto tempo e ragionamenti per capire quale metodo devo chiamare per effettuare una certa operazione oppure peggio ancora mi spingono intuitivamente a chiamare quello sbagliato! Non sarà mai possibile applicare una strategia "perfetta" ai nomi che diamo ai nostri "oggetti", visto che la comunicazione e il linguaggio sono aspetti molto complessi, ma un po' di attenzione, di rigore e di riflessione fanno la differenza.

• Abstraction details

  Così come un cruscotto di una macchina pieno di pulsanti e/o non bene organizzati forse con un eccesso di gruppi, il modo e il livello di astrazione con cui disegnamo il nostro sistema puo influire sulla complessità di comprensione e utilizzo dello strumento.

• Test Driven Development

  La pratica dello sviluppo guidato dai test o TDD è utile per obbligarci a modellare i contratti pubblici della nostra applicazione prima del loro dettaglio implementativo. In particolare quando penso ai contratti pubblici non mi riferisco solo ai nomi dei metodi ma anche ai nomi delle classi e alle strategie e al dettaglio di astrazione del nostro modello ad oggetti.

• Convention Over Configuration

  Quando alcuni anni fa, in un grosso progetto in cui lavoravo, decidemmo di adottare nello sviluppo del nostro software alcune soluzioni "enterprise" ci appoggiamo ad una factory open source derivata da java totalmente configuration driven dove era necessario specificare nel file di configurazione tutto il dettaglio di come construire gli oggetti e iniettare le dipendenze, pur valorizzando la potenza di questo livello di configurazione, dovendo lavorare con domini molto complessi, di centania di componenti, il dettaglio della configurazione stava diventando il nostro tallone di achille. Così decidemmo di intervenire, allora analizzai tutto ciò che poteva essere definito implicitamente per convenzione e sviluppando un sistema automatico di configurazione e l'ausilio di attributi nel codice, con un investimento relativemente ridotto abbiamo portato in carreggiata la competitività del prodotto aumentando produttività e qualitità. La "convention over configuration" se applicata bene (identificando con opportuna attenzione le "reali" convenzioni) rende lo strumento software più produttivo e malleabile, in altre parole più ergonomico.