Da qualche settimana ho cambiato lavoro: ho lasciato la società di consulenza e adesso lavoro per un gruppo piuttosto grande, anche qui come sviluppatore.
I cambiamenti non sono stati solo esteriori, ma anche di contenuto. Infatti sono passato dallo sviluppo Java/Oracle a quello C#/SqlServer. “Oddio!” direte voi… beh, all’inizio lo dicevo anch’io.
Sto valutando le analogie e le differenze tra questi due mondi, cercando di riutilizzare al massimo l’esperienza che ho in Java nel nuovo ambiente. Ora, da utente e da contributore dell’Open Source, passare a M$ mi fa abbastanza impressione, ma considero il mio un lavoro che usa l’astrazione, quindi mi devo slegare dal pensiero del “basso” livello (linguaggi, compilatori, sistema operativo), e devo pensare al codice e a quanto bene sono capace di scriverlo, a come possa funzionare il programma che faccio, senza altro. Sì, questo potrebbe sembrare un esercizio di retorica o di teologia informatica…
Ora comincio con le considerazioni che sto facendo da quel poco che ho imparato nell’ambiente M$, spiegando un po’ l’effetto che mi fa.
Prima di tutto devo ribadire che lavoro per una grande azienda, quasi tutti gli utenti hanno client Windows, ci sono decinaia di server attivi, dall’AS/400 al Linux, da Sap con NetWeaver all’ultimo WS2003 con Sharepoint. C’è chi lavora in Cobol (ancora!), chi è espertissimo di VBA, c’è gente che fa in Excel robe che credevo impossibili (sul grado di affidabilità dei risultati non metterei la mano sul fuoco), c’è tanto lavoro in Java e altrettanto in C#.
Ora, quello che M$ permette, in virtù della sua posizione quasi monopolistica, è un altro grado di integrazione: condivisione dei dati, remote desktop, deploy delle applicazioni. Il lato negativo è che, come dice nonmiricordochi, “fai un programma a prova di stupidi e solo gli stupidi lo useranno”. Non siamo a questo punto, però il fatto che la programmazione per Window$ sia piuttosto semplice, corrisponde al fatto che i lavori non sempre sono eseguiti con rigore.
Faccio due esempi.
Comincio con la gestione delle eccezioni in C#: esiste ma non è obbligatoria. Cioè tu puoi eseguire un metodo che potenzialmente può generare un’eccezione e non prendertene carico. In Java è obbligatorio gestire l’eccezione, e l’errore di non farlo viene segnalato a compile-time. In C# puoi scrivere tutto il codice che vuoi senza usare mai try{} – catch(){}. È una cazzata! Un oggetto genera un’eccezione, non gestita, e si schianta tutto il programma. Ora questo modo di fare avvicina i “programmatori”, perchè è “facile” programmare così, ma il codice e il programma che ne esce è debole.
Secondo esempio: ASP.Net è la controparte web delle applicazioni Web, ed usa lo stesso paradigma degli eventi. Ogni pagina web è un “form” allo stesso modo che in un’applicazione client. E allo stesso modo risponde agli eventi, tipo button_click, che esistono sul client. Questo rende “facile” per un “programmatore” scrivere sia codice per client che per web, perchè sono praticamente identici. Ma in questo modo non c’è una chiara separazione del modello dalla presentazione e dal controller (ossia non c’è un paradigma MVC dietro) e lo “spaghetti code” imperversa. E inoltre la parte di presentazione, di default, è renderizzata con codice HTML 4.01, con un sacco di javascript auto-generato da visual studio. volendo si può costringere la pagina a usare codice XHTML 1.0, ma volendo usare XHTML 1.1 Strict, i controlli web non funzionano perchè sono fuori standard.
Il css non esiste. Questo perchè Visual Studio ti permette di definire le proprietà degli oggetti della pagina in modo “così semplice”, che scrive lui tutto lo stile per gli elementi in modalità “in-line”! Quindi se ti va di cambiare il colore delle pagine devi andare a modificarle tutte, invece di cambiare una riga nel css…
Insomma, l’approccio generale mi sembra questo: “guarda che bei bottoni colorati, clicca qui e là, è facilissimo programmare…” e il risultato è lo spaghetti-code.
In Java si può scrivere codice bruttissimo, ma un minimo di “metodo per fare le cose per bene” c’è, e questo in C# mi manca
ma io ormai sono in ballo, e cercherò di ballare meglio possibile… alla prossima (e via alla flame war!)