Chi ha paura della OOP

La programmazione orientata agli oggetti è un modo di modellare la realtà in un ambiente astratto, virtuale, cioè fondamentalmente è un modo di pensare.
E' nata negli anni 80 per migliorare la qualità dei programmi, riducendo il codice ripetuto e le dimensioni della parte 'alta' del programma, cioè permette di concentrarsi sulla macro area, delegando i dettagli a parti che non si vedono.

Si creano dei componenti riutilizzabili, tali che sempre più spesso scrivere un programma diventa un assemblaggio di parti, privilegiando la manutenzione, spesso a dispetto delle prestazioni, ottenute grazie al miglioramento delle prestazioni dell'hardware moderno.

Anni fa si scatenò l'entusiasmo dell'industria informatica, che finalmente vedeva la possibilità di creare software con criteri industriali, cioè potendo finalmente ottenere risultati paragonabili con produzioni simili e con una certa attendibilità nelle stime dei tempi di sviluppo.
I più ottimisti immaginavano anche dei mercati di componenti software, più o meno come 30 anni dopo qualcuno immagina che ci possano essere dei servizi su Internet utilizzabili da applicazioni diverse, creando una sorta di "nuvola" dell'informazione.

Poi è successo qualcosa che ha inceppato questa visione quasi positivistica, mi si consenta, della realtà dello sviluppo: un uso semplice dei componenti implica una progettazione per nulla banale.

E qui viene il difficile: se la OOP è un modo di pensare, allora progettare bene significa pensare bene.

Pensare è un'attività difficile, che si impara con l'allenamento, in natura siamo istintivi. E' l'educazione e il duro allenamento alla logica che compiono il 'miracolo'. Poi ci sono persone più o meno portate, ma più spesso ci sono persone che sono state allenate prima dall'ambiente dove sono cresciute.

Progettare in OOP è un modo più naturale, rispetto alla programmazione procedurale, dove si "naviga a vista" nel codice, proprio perché si parte da un modello, cioè un'astrazione che mappa la realtà, ma chi non ci è abituato, spesso trova questo approccio difficile, si scoraggia e si trova ad essere molto meno produttivo di prima, magari perché applica male le tattiche della OOP.

Pensare, progettare, richiede Tempo. Purtroppo il tempo è una risorsa limitata nei progetti. Pochi stakeholder accettano che si spenda tempo in pensieri, anziché in azioni, quindi la fase di progettazione/studio è rilegata nella migliore delle ipotesi a qualche giorno all'inizio del progetto. Risultato: progetti che diventano un vero incubo e morale sotto i tacchi, responsabili che sentono traballare le loro seggiole e che cominciano ad innervosirsi e perdono la loro funzione di collante tra i membri del progetto.

La realtà è semplice nella sua tristezza: non è possibile determinare quanto tempo occorre per avere un'idea.
Le stime in questo caso sono una serie di approssimazioni. Si può stimare solo un lavoro simile ad uno (o più di uno) già di fatto.
Per ovviare a questo problema, l'industria (?) informatica sta virando dal periodo d'oro della OOP verso la produzione di strumenti, che consentono di puntare dritti sull'obbiettivo, cioè si rinuncia a dover pensare, ci si deve fidare della strada tracciata da chi ha già pensato per noi, in modo da tagliare i tempi.
In pratica si prega e ci si affida allo strumento, che deve essere pensato che aiutarci nei nostri casi d'uso.
Quindi conviene forse conoscere n strumenti per non rischiare di applicarli a casi d'uso per i quali non sono stati progettati? Logicamente cercando di non legarsi al singolo fornitore di questo o quello strumento.
E' un vero vantaggio? Non converrebbe forse cercare noi, di specializzarci in un dominio applicativo, che conosciamo, comprare/usare/creare le librerie che ci servono e godere poi dei vantaggi del riutilizzo di tali strumenti, come immaginavano i pionieri, che negli anni 80, hanno rivoluzionato il mondo di concepire il software con la OOP?

La OOP è utile, non va ritenuta la panacea di tutti i mali, non sostituisce il bisogno di ascoltare le persone, non è una mera applicazione di pattern, però se compresa nei suoi intimi dettami, è un'ottima soluzione tecnica per produrre codice migliore e avere meno gente che ci chiama ad orari impossibili, per segnalare bug, oltre che un ottimo rimedio per TAGLIARE i tempi di sviluppo.

Quello che molti stakeholder non comprendono subito, è che il tempo investito nella progettazione, ritorna in tempi di sviluppo più brevi e questo beneficio molto spesso si protrae nel tempo.
Pensare prima di agire è un vantaggio. Creare qualcosa di piccolo, che poi va buttato perché si è pensato poco, non è conveniente nel lungo periodo.

Oggi ci si affida molto ai test automatici e questo è giusto, ma quando poi ci si trova a buttare sia il core che il test, azione eufemisticamente detta "refactoring", viene da chiedersi se non sarebbe stato meglio spendere  giorni uomo in più per capire il dominio applicativo! Capire, modellare, poi scrivere il codice, certamente documentato e corredato da test, ma senza doverlo rifare 3 o 4 volte, ad ogni iterazione. La mia impressione è che spesso lo sviluppo 'moderno' cerchi solo di sdoganare le cattive abitudini dello sviluppo 'antico'.

Pare inoltre che il risultato del pensiero iniziale, non sia solo la soluzione del problema contingente, ma anche una migliore abilità nei pensieri che seguiranno, già questo dovrebbe essere un ottimo stimolo per non avere paura di fermarsi a riflettere.

Per finire, ci sono aziende che proprio non consentono questo approccio. In queste realtà il programmatore è un produttore di codice da vendere, come una gallina produce uova da vendere. Uova, cetrioli o procedure sono trattati allo stesso modo da quei signori.

Se il lettore si trova in uno di questi posti, il consiglio che mi sento di dargli è quello che trovai anni fa, scritto su un libro di UML: se non puoi cambiare l'ambiente dell'azienda dove lavori, prova a cambiare azienda !

La vera forza di Java

Sempre più spesso si trovano articoli che confrontano i vari linguaggi di programmazione e le varie tecnologie tra di loro.
I tecnici discutono, spesso animatamente, come tifosi se sia meglio un linguaggio o un altro, perché nel criterio di scelta della tecnologia si proietta il nostro modo di scegliere, mettiamo in gioco la nostra capacità di valutare e di scegliere. Una bocciatura alla nostra scelta da parte di un collega, si proietta in una bocciatura a noi stessi, alla nostra capacità e, in definitiva, tale atteggiamento va a toccare le corde della nostra insicurezza.
Col tempo ho imparato a guardare con un certo distacco alle discussioni di questo tipo.

Oggi è più significativo confrontare i framework, piuttosto che i linguaggi. Non è più come negli anni 80 dove si imparavano 15 istruzioni e uno credeva di sapere programmare.
Si programma delegando a componenti esterni i dettagli. Il lavoro del programmatore sembra sempre di più quello del regista di teatro, che dirige degli attori, ma non è egli stesso l'attore.

Esistono ancora realtà dove si programma come un tempo, ma spesso spendono soldi e risorse per farsi in casa lavori già disponibili, solo che non ne conoscono l'esistenza. Ognuno coi suoi soldi è libero di fare come crede.

La prima domanda, che uno sviluppatore o meglio un architetto del software si deve porre, è come il lavoro, che deve realizzare, si interfaccia col mondo esterno, non soltanto sul piano della comunicazione, cioè dei messaggi in ingresso e in uscita, ma anche sul piano dell'ecosistema di strumenti e ambienti nel quale il progetto nasce e si sviluppa, cioè convive.
Ho conosciuto realtà che ogni anno riscrivevano da 0 il progetto, perché non erano più in grado di espanderlo o di modificarlo, perché il programmatore principale del progetto se ne era andato (chissà perché) oppure perché mancava documentazione, ma più spesso perché il progetto era stato analizzato male. Si vedono realtà che danno una enorme importanza alla gestione economica del progetto, ma non hanno la cultura e nemmeno l'abitudine all'analisi. L'atteggiamento di fermarsi a pensare prima di agire non è un'ostacolo all'agilità, anzi è una risorsa che col tempo fa risparmiare in rifacimenti inutili.

Come succede nei giochi di strategia a turni, i primi turni sono i più importanti e determinano spesso l'andamento della partita.
In questo scenario, non è significativo determinare se C# è migliore di Java perché ha Linq o se il C++ è meglio di entrambi, perché può usare meno risorse o se conviene o meno sviluppare in casa un framework per la persistenza o usarne uno standard.

Java è a mio avviso ancora la scelta migliore perché Java non è solo un linguaggio o un framework con un ricco ecosistema: Java è una specifica.

Si possono realizzare virtual machine compatibili, librerie compatibili ma di fondo esiste una regola, che è la specifica. La serietà di chi fa le regole e la fiducia di chi le segue è la forza di Java e in questo è superiore alle altre soluzioni, che sono pilotate spesso da una sola azienda, mentre nell'ecosistema di Java sono sempre convissute più realtà importanti.

La regola, la specifica dettata dall'alto, da un valore aggiunto enorme: la sicurezza dell'investimento.

Questa governance è stata la madre del successo e della diffusione di Java, al di là di alcuni suoi limiti tecnici (l'uso eccessivo di memoria) o di scelte discutibili (Swing che non usa i widget nativi).
La forza di Java è stata la politica di apparire come una regola, più che una tecnica.

Poi ciascuno di noi può proporre una proprio approccio alternativo a quello ufficiale, nel mio piccolo l'ho fatto anche io con EasyDriver ma non si può aspettare che i nomi che contano aderiscano alla sua proposta, se non si trova sotto il cappello del governo delle specifiche di Java.

Sinceramente sono un po' perplesso sulla politica usata ultimamente da Oracle, che vede troppe frizioni, in un ambiente che è diventato forte grazie agli accordi, che rendevano inutili i fork. Prima di tutto viene la specifica, la regola. Litigare con l'impagabile Apache Foundation e con Google non sta aiutando certamente l'immagine della piattaforma, ma il colpo finale sarebbe non potere più contare su una specifica credibile. Questo sarebbe un male per tutta l'industria informatica, cha ha tratto giovamento da questa rivoluzione, chiamata Java, e che farebbe un brutto salto indietro, se dovesse diventare un framework governato come gli altri.

Come imparare a programmare ?

Un tema spesso dibattuto sul web e fonte di ansia per un giovane appassionato di computer, è come imparare a fare da soli, almeno un po' delle cose che si vedono girare sul computer appena comprato: cioè come imparare a programmare.

Il pensiero comune e il consiglio che ai miei tempi (fine anni 80) mi veniva dato, era di non pensare a cercare una scuola che insegnasse a programmare, perché lo avrei imparato più tardi all'Università.

L'informatica centra con i computer non più di quanto l'astronomia centri con i telescopi (Dijkstra).
Purtroppo l'università pare centrare con la programmazione non più di quanto una scuola alberghiera centri con la scaloppina che mi preparo stasera, leggendo il mio libretto di ricette. (Io, col dovuto rispetto per Dijkstra).

Ai tempi della scelta dell'università, qui in Italia, si vedeva con sospetto, che Informatica era una variazione di Ingegneria, con un biennio quasi uguale. Quindi ore e ore passate non tanto ad apprendere teoria, quando ad immergersi nell'astrazione.

Dopo 5 anni di  liceo scientifico maxisperimentale di Lugo quasi completamente inutile al mio scopo, un ingegnere, che dirigeva una software house, mi consigliò di non rimanere "parcheggiato" per anni all'università, bensì di frequentare un corso professionalizzante, che mi insegnasse cosa mi serviva veramente. Ne trovai uno a Forlì, di un anno, finanziato dalla comunità europea. Seguii il consiglio e ne fui soddisfatto.
Incontro oggi spesso dei laureati in ingegneria e in informatica, i quali lamentano che solo un 10% di ciò che hanno imparato, serve veramente nel mondo del lavoro. Sulla presunta flessibilità mentale poi, anche la settimana enigmistica aiuta il cervello...

Oggi la situazione è migliorata, nel senso che anche all'università si stanno rendendo conto che sapere disegnare una parabola col Pascal, non è proprio ciò, che il mercato cerca.

Il mercato esiste, bisogna che anche gli intellettuali e gli accademici se ne accorgano.

La riforma universitaria della Moratti doveva servire a creare delle scuole professionalizzanti, sulla falsa riga di quelle europee, inglesi e tedesche in primis.
L'obbiettivo, secondo me, è stato mancato prima di tutto perché l'approccio di noi latini, e degli italiani in particolare, è ben lontano dal pragmatismo anglosassone.

Ci piace il bizantinismo al punto tale, che ci sembra necessario. Per andare da un punto A ad un punto B non si cerca la strada più breve, il segmento, bensì la curva che politicamente accontenta più fazioni, come se dei poli magnetici deviassero il percorso...

Le lauree brevi triennali, continuano a dare un'offerta formativa troppo astratta, che non si spende sul mercato, e non fornisce, per ragioni di tempo contingentato, le basi necessarie per affrontare gli argomenti più avanzati, col doppio risultato, che raggiungere la laurea è difficile, perché il percorso non offre ad ogni tappa le basi utili sulle quali poggiare l'apprendimento per gli esami successivi, poi perché l'offerta non è sufficiente affinché il mercato possa assorbire i neolaureati senza costi di formazione specifica.

Se si considera che in azienda di formazione se ne fa pochissima perché "con la crisi bisogna tagliare le spese", figuriamoci come possono aspettare che un neo assunto apprenda ciò che gli serve sul campo.
Il risultato reale è che solo chi si adatta velocemente ad un posto di lavoro poco formativo, sopravvive in azienda, per gli altri è precariato.

Invece che lamentarsi sempre per i fondi troppo scarsi, a ragione, le università dovrebbero rivedere il loro rapporto con le imprese e con il mondo del lavoro, smettendo di guardarlo dall'alto in basso, in attesa che lo Stato, se può, imponga una riforma ancora più radicale, cioè in attesa che l'Europa ce la imponga, come se fosse un tutor che rimedia alla nostra incapacità di reggerci sulle nostre gambe.

Per rispondere alla domanda che si può porre un giovane appassionato di computer di oggi, io direi:
"non aspettare fino all'università, ma comincia da subito a studiare magari in un istituto tecnico ad indirizzo informatico oppure a ragioneria programmatori. Comunque fai quello che ti piace e nessuno ti impedisce di avvicinarti a qualche manuale americano di ingegneria del software. Impara bene l'inglese, ma soprattutto sfoga la tua creatività naturale, magari programmando".

Qualche facoltà, piano piano, prova a cambiare il cliché che vede la programmazione come matematica applicata. Trattandosi di una materia così interdisciplinare, è bello vedere sorgere corsi di studio come Informatica Umanistica a Pisa, che forma un background utile nel mondo della conservazione dei beni culturali (il vero  petrolio italiano), oppure a Trento una facoltà di Interfacce e Tecnologie per la Comunicazione, inserite nella facoltà di Scienze Cognitive, oppure Informatica per il Management a Bologna, con nozioni di economia e diritto.

Avendo fatto il programmatore professionista per 15 anni, ho sempre sentito la mancanza di un background  di economia aziendale, diritto di internet e psicologia (provate a lavorare in team o a entrare in una qualsiasi azienda e vi renderete conto di quanto valga l'intelligenza emotiva...)

Ciao !