Programmare il programmatore

art. postato da Angela Delicata su uictech, 25\11\2009, h. 19.59.

Fonte:
http://punto-informatico.it/2759832/PI/Interviste/programmare-programmat...

Ed ora, un po' di pubblicità

Programmare il programmatore

mercoledì 25 novembre 2009di Luca Annunziata

Programmare il programmatore
Faccia a faccia con uno dei papà di Visual Studio. Che racconta il percorso che
conduce da una release alla successiva. E spiega che nella vita è più facile
immaginare cosa desideri uno sviluppatore piuttosto che un avvocato

Roma - Brian Harry, product manager del team che sviluppa Foundation Server per
Visual Studio di Microsoft, ce lo presentano come un guru per l'ambiente dotNET.
In Italia per una conferenza con gli sviluppatori del Belpaese, ha accettato di
fare quattro chiacchiere con Punto Informatico: ne è venuta fuori una
discussione sulla vita del programmatore e cosa c'è all'orizzonte per chi fa
questo lavoro. Il tutto alla vigilia del rilascio della nuova versione di uno
degli IDE più utilizzati in ambiente Windows.

Punto Informatico: Da qualche settimana è disponibile la beta 2 di Visual Studio
2010. Secondo alcuni addetti ai lavori, l'evoluzione di questa versione ricorda
vagamente quello che era accaduto agli esordi dell'IDE Microsoft, all'epoca di
Visual Basic: non c'è il rischio che la distanza tra il codice vero e il livello
a cui si programma si ampli troppo?
Brian Harry: Il lavoro degli sviluppatori si va facendo sempre più sofisticato,
le applicazioni diventano sempre più complesse sul piano delle feature e del
tipo di dati che devono trattare: video, animazioni e così via. In qualche modo
bisogna tentare di aumentare l'astrazione a cui lavorano i programmatori,
altrimenti gestire questo tipo di applicazioni rischierebbe di diventare
impossibile.

PI: Ad esempio?
BH: Dalle versioni 2000 in avanti, Visual Studio ha sempre offerto diversi
livelli di astrazione. Un esempio buono per spiegarsi può essere Silverlight e
le applicazioni abbinate: posso decidere di lavorare sulle animazioni, sulle
trasparenze e le transizioni senza toccare il codice, oppure posso andare
direttamente sul codice stesso per ottimizzare le singole parti. Tutto dipende
dal tipo di lavoro che si intende fare. È una questione di essere produttivi ad
alto livello mantenendo il controllo a basso livello, evitando che si creino due
mondi distinti e scollegati.PI: Il concetto di ottimizzazione è senz'altro
fondamentale: in che modo l'ambiente di sviluppo può aiutare in questo senso?
C'è senz'altro una differenza netta tra le prestazioni necessarie per una
piccola applicazione o un piccolo sito, e quanto occorra fare per un progetto di
grandi dimensioni.
BH: Certo, creare un'applicazione che vada bene per milioni di utenti è molto
differente rispetto a crearne una per poche decine. Ci vogliono conoscenze e
competenze differenti, creare un'applicazione scalabile e funzionale non è certo
un risultato ottenibile partendo unicamente da un template. Per questo abbiamo
dei percorsi specifici pensati per creare questo tipo di applicazioni.

PI: Quali sono i fattori da tenere in conto?
BH: Bisogna tenere in conto fattori diversi, non scontati, come ad esempio il
caching. Bisogna avere uno sguardo di insieme sull'architettura, per gestirla in
modo efficiente. Il programmatore medio spesso non ha bisogno di comprendere
queste problematiche fino in fondo, e con gli strumenti che ha difficilmente può
riuscirci: in questo senso c'è un punto di rottura oltre il quale gli strumenti
standard non bastano per produrre un'applicazione realmente scalabile. Noi però
lavoriamo anche per creare gli strumenti che siano in grado di renderlo
possibile, anche se per arrivarci occorre un impegno ulteriore da parte dello
sviluppatore.

PI: Tra le novità di Visual Studio 2010 ci sono degli strumenti di testing
automatici: possono essere un aiuto per ottimizzare ad alto livello?
BH: In quel caso non è questione di ottimizzazione, sono strumenti pensati per
garantire la correttezza sintattica del codice. Abbiamo comunque anche dei test
di carico che accoppiati a questi nuovi strumenti possono aiutare a simulare il
traffico di migliaia di utenti e individuare rapidamente eventuali problemi.
Mettendoli assieme si riesce a comprendere facilmente quale sia il comportamento
del sistema "sotto sforzo" e come reagisca l'applicazione.

PI: L'IDE si evolve a ogni aggiornamento, si arricchisce di nuove funzioni: c'è
un limite alla complessità che possono raggiungere questo tipo di strumenti?
BH: No, direi di no. L'unico punto di rottura si verificherebbe se la tecnologia
smettesse di evolversi, se non sorgessero nuovi tipi di paradigmi di
programmazione, nuove tipologie di servizi, nuove categorie di utenti. Semmai il
problema è che ci sono moltissimi strumenti diversi all'interno di Visual
Studio, con finalità diverse: occorre trovare il modo di renderle disponibili
coerentemente all'utente, e ci sono delle soluzioni specifiche come i Web
Express Tools o quella per C++. Abbiamo cercato di ricreare quel tipo di
esperienza mirata anche nella versione completa di Visual Studio, per consentire
di sfruttare ambienti più "targettizzati" per un singolo tipo di applicazione in
via di sviluppo.

PI: In effetti capita spesso, però, di lavorare con una versione dell'IDE e del
runtime che non sia l'ultima disponibile. Magari non è necessario. Oppure si
lavora con un sottoinsieme delle possibilità del runtime utilizzato. Verrebbe da
citare di nuovo il caso di Visual Basic: la sua sparizione in qualche modo
rappresenta una certa evoluzione delle esigenze degli sviluppatori e degli
utenti?
BH: Interessante l'esempio di Visual Basic. Non abbiamo abbandonato Visual Basic
perché pensavamo di averlo portato al suo sviluppo massimo, abbiamo pensato
piuttosto che il percorso tecnologico di Visual Basic non era la visione giusta
da portare avanti, che cioè fosse in grado di resistere altri 20 anni sulla
piazza. Quindi è venuto dotNET, il runtime: un cambio notevole nel modo di
intendere e costruire le applicazioni, ma un cambio necessario.

PI: Un cambio necessario?
BH: C'erano tante applicazioni lato client in Visual Basic, ma abbiamo percepito
un graduale spostamento verso il concetto di web application. Abbiamo scelto una
piattaforma che giudicavamo giusta per quel cambiamento. C'è un altro
cambiamento interessante in atto, quello della cloud, che sarà affascinante
capire come influenzerà i nostri strumenti: quello che facciamo oggi è costruire
applicazioni tradizionali in grado di sfruttare la cloud, ma cosa succederà
quando saranno gli strumenti stessi per creare le applicazioni a risiedere nella
nuvola? Come si fa un debug nella cloud? Non so dire cosa succederà esattamente,
ma credo che quello sarà il nuovo mondo da esplorare per lo sviluppo a lungo
termine nei prossimi anni.PI: Si parla molto di cloud computing, ci sono molte
iniziative anche commerciali al riguardo, ma pare che nell'attuale comunicazione
su Visual Studio ci si concentri maggiormente su Silverlight che su Azure.
BH: Molti annunci per Azure sono stati fatti al PDC (da Ray Ozzie, ndr), ed è
passato solo un anno da quando è stato annunciato. Prima di passare alle
applicazioni stiamo lavorando sulla piattaforma, e gli strumenti per Azure
saranno comunque rilasciati al di fuori del normale ciclo di sviluppo proprio
per accelerarne l'uscita.

PI: A proposito di cicli di vita delle applicazioni, si stanno facendo davvero
brevi: in alcuni casi sono addirittura di sei mesi. Come ci si confronta con
queste novità, anche Visual Studio andrà incontro a questo tipo di
accelerazione?
BH: Lo faremo dove e quando avrà senso: in generale agli addetti ai lavori non
fa piacere dover procedere agli upgrade, e in certi ambiti - come la cloud -
occorre garantire almeno un paio d'anni di stabilità per riuscire a "stare sui
server". In altri casi, come Silverlight, il ciclo di vita è sceso ormai sotto
l'anno: per i device tool, che prima erano inglobati nel ciclo di sviluppo di
Visual Studio, abbiamo deciso di adottare un approccio differente e abbinarli
all'uscita di nuovi prodotti. Dove ha senso, aggiusteremo il life cycle per
adattarlo al tipo di ambiente in cui ci si muove.

PI: Qual è il ciclo di vita ideale, se ne esiste uno?
BH: Il life cycle ideale è probabilmente attorno ai due anni. Abbiamo pensato
anche a fare release più piccole molto frequenti, come nel caso dei power tool
che vengono pubblicati ogni tre o quattro mesi e che praticamente implementano
feature in tempo reale. Pensiamo spesso a queste problematiche, e la risposta
vera è che probabilmente dipende dalle esigenze specifiche.

PI: È uno scenario accattivante per uno sviluppatore?
BH: Se mi piace? Sì, mi piace, ma è complicato: ci sono cose che non si possono
fare in temi ristretti. La mia idea è che ci sia bisogno di un modello con life
cycle concorrenti, dove ci siano progetti che vanno avanti per qualche anno,
anche quattro o cinque, così da avere il tempo di incubare e sviluppare novità
importanti. Nel frattempo ci saranno altri progetti sviluppati con passo più
rapido: ad ogni rilascio ci sarà l'occasione per confrontarsi con il proprio
pubblico, anche per raccogliere un feedback utile a capire se ci si sta muovendo
nella direzione giusta.PI: Non è la prima volta che ci si misura con queste
problematiche.
BH: Bisogna andarci coi piedi di piombo. A metà degli anni '90 abbiamo fatto
delle sperimentazioni con il C++ e con release ogni tre mesi, ma poi ad ogni
trimestre non c'era molto da rilasciare visto che la maggior parte del tempo
veniva speso nel rifinire il codice in vista della release imminente invece di
implementare nuove feature.

PI: Ci sono scenari recenti che possano cambiare la prospettiva?
BH: Facciamo un esempio: se mi chiama un cliente per chiedermi qualcosa, e io
gli rispondo che per implementare quelle funzioni nel mio ciclo di sviluppo mi
servono due anni e mezzo, probabilmente quel cliente me lo perderò. Due anni e
mezzo sono un'eternità. C'è una soluzione possibile, ovvero l'hosting di
servizi: anche noi ne gestiamo uno interno. Consente di patchare un servizio in
un giorno invece che in settimane, come accade quando si deve affrontare uno
sviluppo per una applicazione esterna, e diventa possibile combinare programmi a
breve termine e in piccolo con altri a lungo termine e di grande respiro.

PI: Parliamo di device, un settore dove altri concorrenti come la piattaforma
Java hanno un ruolo diverso da dotNET. Ci sono strade diverse che potrebbero
essere imboccate?
BH: Fino a oggi c'è stata una stretta correlazione tra la versione di Visual
Studio e la versione di runtime utilizzata: con il 2010 stiamo cambiando alcune
cose, e con lo stesso codice sarà possibile compilare per diverse versioni di
runtime.

PI: In ogni caso dotNET resta un ambiente pensato quasi esclusivamente per il
mondo dei PC, se così si può dire.
BH: Ci abbiamo pensato, ma prendiamo il caso dei cellulari: dotNET già funziona
su quelle piattaforme. Silverlight è un pezzo di dotNET che funziona in molti
ambienti diversi: certo, non siamo ancora in grado di far funzionare un
aspirapolvere e una lavatrice, ma potenzialmente siamo in grado di arrivare su
parecchi dispositivi. Non abbiamo mai raggiunto un livello di ricchezza di
device di Java, ma è anche una questione di livello di costo: Linux, Java sono
praticamente gratuiti e hanno un'incidenza diversa su piattaforme più
economiche.

PI: È possibile quindi che, nonostante il discorso sulla complessità degli
strumenti che facevamo prima, dentro Visual Studio prima o poi si facciano
strada strumenti per altre piattaforme? Magari iPhone, o Android.
BH: Visual Studio è una piattaforma: non tutto quello che c'è dentro Visual
Studio, come ad esempio gli strumenti per la gestione di SQL, è realizzato dal
team di Visual Studio. In effetti, la lista di parti che si integrano dentro
l'IDE è molto lunga. iPhone in Visual Studio? Non saprei, non ho idea di quel
potrebbe voler fare Microsoft. Se qualcuno lo facesse, però, ci sarebbero molti
vantaggi per tutti: sarebbe uno strumento utile alla portata di molti, sarebbe
senz'altro interessante.Un'altra questione riguarda il numero di linguaggi
gestiti da Visual Studio: sono molti, in qualche modo forse anche troppi.
Microsoft non potrebbe concentrare gli sforzi nel creare una piattaforma
trasversale per tutti gli ambienti nei quali opera, dalla robotica ai personal
computer?
BH: dotNET è la nostra piattaforma di programmazione e lo resterà ancora per un
bel pezzo. È in grado di funzionare in tutti gli ambienti nei quali Microsoft
opera, ed è ovviamente il risultato di un compromesso tra diverse esigenze. In
generale, non parlo di Visual Studio, negli ultimi anni c'è stata una
proliferazione di linguaggi di ogni tipo, linguaggi per domini specifici, con
librerie diverse ed espressività differenti, creati magari per risolvere
problemi particolari o soddisfare particolari esigenze: è una cosa ottima,
significa che c'è movimento nel settore, ma pone anche alcuni interrogativi.
dotNET per il momento resta il nostro ambiente multilinguaggio: ma non è escluso
che in futuro in questo senso cambi qualcosa.

PI: Questo conduce a un'altra domanda: come si fa a decidere quali cose devono
cambiare in questo tipo di strumenti? Ad esempio: qual è e come si determina il
corretto compromesso tra sviluppo visuale e del codice?
BH: È una parte molto complessa del nostro lavoro. Parliamo moltissimo coi
clienti, cercando di capire cosa vogliono davvero: alla fine cerchiamo di
intuire quale sia il desiderio della "maggioranza", perché includere tutto non
sarebbe pensabile. Cerchiamo anche di tener conto degli investimenti, nostri e
altrui, per garantire che le risorse impiegate in una direzione non vadano
perdute.

PI: Esiste un metodo per fare tutto questo?
BH: Mettiamola così: per la prossima versione di Visual Studio passeremo almeno
quattro mesi a fare "data gathering", parlando con clienti e partner, osservando
i trend di ambienti come la cloud e i device. Non faremo altro che "imparare",
capire cosa stanno facendo gli sviluppatori in questo momento. Poi ci saranno
altri due mesi di brainstorming: tireremo fuori idee che potranno concretizzare
le tendenze che abbiamo visto all'opera. E poi, per un altro mese affineremo i
concetti, chiarendo quello che sarà o non sarà possibile realizzare nell'arco di
tempo prestabilito dal progetto. Direi che questa fase terminerà nella prima
metà del 2010.

PI: Com'è lavorare sugli strumenti che altri useranno per lavorare? Sviluppare
un IDE è un po' come realizzare dei mattoni che verranno costruiti per costruire
una casa: occorre tentare di prevedere tutte le esigenze che gli sviluppatori
avranno nel loro lavoro?
BH: Credo che il mio sia il lavoro più facile che uno sviluppatore possa
affrontare: costruisco gli strumenti che a mia volta utilizzerò per lavorare. Il
mio primo lavoro è stato per un'azienda che sviluppava applicazioni per l'email,
molto tempo prima che Internet diventasse di uso comune: la posta elettronica
era uno strumento ad uso interno per contabili e avvocati, ma non essendo mai
stato io un contabile o un avvocato non avevo idea di quali fossero le loro
esigenze. Il bello di sviluppare strumenti per sviluppatori è proprio questo:
sono uno sviluppatore anch'io! So di cosa ho bisogno, so se qualcosa è fatto
bene o è fatto male: mi piace molto fare questo lavoro.

PI: È mai capitato di rilasciare qualcosa che fosse "fatto male"?
BH: Certo, capita a tutti.

PI: E cosa è successo?
BH: Ho cercato di sistemarla prima che ho potuto. (sorride)PI: Prendiamo il caso
di un'interfaccia: come si fa a decidere quale sia quella giusta per un IDE? Nel
corso degli anni stanno anche cambiando le dimensioni dei monitor in uso negli
uffici.
BH: Può sembrare banale, ma non c'è niente di più importante che ascoltare i
propri utenti. In particolare bisogna ascoltare due cose: quali siano i loro
problemi, e quali siano i loro suggerimenti per superarli.

PI: E cos'è più importante tra le due?
BH: Bisogna porre molta attenzione: ascoltare i suggerimenti non aiuta a trovare
nuove strade per risolvere i problemi. Il nostro compito, invece, è ascoltare i
problemi e fare un passo indietro: cercare di rivedere l'intero processo che ha
condotto a quell'impasse per tentare di risolvere il problema alla radice.

PI: È un processo simile a quello di un prodotto come Office?
BH: Nel caso di Office, il problema era che c'erano molte feature e le persone
ne utilizzavano un piccolo sottoinsieme: l'interfaccia Ribbon (quella di Office
2007, ndr) aiuta a semplificare il meccanismo di selezione. Visual Studio ha un
problema simile, ma anche differente: offre un range di funzionalità anche
superiore a Office, ma nel nostro caso gli utenti usano una grossa fetta degli
strumenti a loro disposizione. Per questo abbiamo un team che si occupa
specificamente del problema: prendono in esame ogni tipo di soluzione, dal 3D a
rappresentazioni grafiche del progetto in via di sviluppo.

PI: Scoperto qualcosa di utile?
BH: In effetti è interessante, ci hanno spiegato che la maggior parte delle
persone ha una memoria che funziona in modo particolare: se gli mostri una foto,
dopo qualche minuto non sono in grado di ricordare in tutto e per tutto cosa vi
fosse mostrato. Ma se gli chiedi di alcuni dettagli, magari dov'era un
particolare oggetto, allora sono in grado di recuperare quella informazione in
un batter d'occhio. È partendo da questo tipo di riflessione che ci muoviamo:
adottiamo una strategia fatta di tanti piccoli ma significativi "passetti", che
ci permettono di gestire e superare questo tipo di problemi complessi.

PI: Un commento di Brian Harry su Visual Studio 2010. A proposito, quando esce?
BH: La data ufficiale di rilascio è il 22 di marzo. Ci sono molte novità in
questa release, alcune come IntelliTrace (un nuovo meccanismo per il debugging,
ndr) stanno ricevendo commenti entusiasti: ma ci sono altre feature
interessanti, per esempio è la prima versione di Visual Studio a includere
strumenti specifici per SharePoint. Chiaramente ciascun sviluppatore avrà
motivazioni diverse che lo spingeranno ad upgradare: la cloud potrebbe essere
una di queste. Sarà una bella sfida convincerli, speriamo bene.

a cura di Luca Annunziata