Riuso e OOP

Oggi sono in vena di ribadire un'ovvietà.
Certamente vi sarà capitato (o vi capiterà) di vivere la seguente esperienza:
il vostro capo/responsabile vi dice che dovete svolgere un dato compito, portare a termine un progetto, ecc. e che sarebbe meglio ricorrere al riuso di parti di questo o quest'altro progetto esistente.
Occhio, adesso arriva l'ovvietà: l'operazione è conveniente se e solo se il progetto di partenza è stato pensato, disegnato e scritto strettamente O.O., altrimenti ecco quello che capita:

- vi ritrovate a copiare/incollare procedure o pezzi di procedure

- sporcate la vostra applicazione con codice fuori contesto

- costruite il vostro codice sulle macerie di un altro progetto, ottenendo un design pasticciato, precludendovi la possibilità di trovare una soluzione migliore.

Questa sorta di riuso all'italiana fa parte del triste retaggio anche noto come "arte di arrangiarsi", applicato al processo di sviluppo del software:

- FASE UNO: scrivi un programmino in fretta, non documentarlo, non pensare nemmeno a un design. Ah, ancora una cosa: indipendentemente dal linguaggio scelto, se proprio devi usarli, usa gli oggetti solo pro-forma, cerca di fare tutto in modo procedurale (So che puoi farlo, non essere modesto).

- FASE DUE: quando servirà un'applicazione per risolvere un problema in qualche modo similare, il tuo successore (perché nel frattempo tu sarai andato a fare il technical manager dalla concorrenza) prenderà i vecchi sorgenti, e nel tentativo di tirar su qualcosa di decente nei tempi imposti farà una minestra di:

- reverse engineering sul tuo codice

- bug fixing del tuo codice

- cross-design tra la vecchia applicazione e quella che si vorrebbe

- codifica modificando le procedure (cioè il core del tuo programma)

tutto questo naturalmente senza accorgersene, senza un planning che dia un nome alle varie fasi di sviluppo, e chiamando infine la suddetta minestra: programmazione.

Questa è la ragione per cui è una buona idea usare librerie di classi pronte (ed esistono aziende il cui business è proprio quello di vendere componenti), mentre generalmente è una cattiva idea cercare di riusare codice scritto per risolvere in fretta un problema.

Metodologie agili??

La situazione dello sviluppo software in Italia è scoraggiante.
Manca una cultura dello sviluppo, la stragrande maggioranza delle piccole aziende che facciano software, o che abbiano un dipartimento di sviluppo, di fatto non utilizza nessuna metodologia, approcciando il processo di produzione del software come fossero piccoli artigiani.

DISCLAIMER: non c'è nulla di sbagliato nell'approccio artigianale, il fatto è che gli artigiani bravi sono pochi: i falegnami che sanno costruire uno splendido comò partendo da semplici assi di rovere sono pochi, e quei pochi impiegano tanto tempo, e si fanno pagare molto.

I programmatori assunti dalla piccola impresa italiana non assomigliano a questi pochi eletti artigiani del legno. Generalmente hanno vincoli di tempo ristretti, sono sottopagati e spesso il loro lavoro non viene apprezzato dai responsabili non-tecnici (quando invece quasi tutti sanno giudicare un comodino ben costruito).

L'artigianato del software assomiglia più alla totale deresponsabilizzazione dei project-manager, project-leader e generici project-something: assumi dei neolaureati, pagali un po' meno della media di mercato, dai loro un compito definito fumosamente, dai dei tempi basati sulle tue impressioni e al termine verifica che lo staff non ha capito cosa doveva fare, i tempi si sono decuplicati, i programmatori si odiano tra loro e odiano i project-something.

Bene, se questa è la situazione nella vostra azienda è meglio chiarire subito e brutalmente una cosa: non siete in grado di mettere su neanche una cassetta per la frutta, altro che comodino in rovere.
Dovete ricorrere a delle metodologie.

I project-something a questo punto ripescheranno nella memoria le paroline magiche che illustrano la strada vincente: metodologie agili, che negli cervelli dei diversi attori si traducono in:

[manager capo]: azienda all'avanguardia, siamo forti!

[project-something]: lavoro fatto bene, meno lavoro per me, più lavoro per lo staff.

[programmatore]: nessun vincolo, nessuna metodologia.

Le metodologie agili funzionano se il team di sviluppo conosce e usa già una metodologia (non agile), altrimenti è molto probabile che un processo agile venga preso come "nessun processo" e si consegni l'intero sviluppo all'anarchia.

Quiz

Immaginate queste situazioni:

a) Il vostro capo parla al telefono, sorride ed è gentile. Sta parlando con un suo superiore.

b) Il vostro capo parla al telefono, fa la voce grossa, è maleducato. Sta parlando con un sottoposto.

---

Il quiz è: se il protagonista delle situazioni (a) e (b) è la stessa persona, se le suddette situazioni non sono sporadiche, ma metodiche, possiamo quindi dedurre che...

1] il capo è un vero leader ed esprime in modo comprensibile a tutti la sua posizione nell'organigramma.

2] il capo ha un cattivo carattere, tratta male le persone. Eccezionalmente riesce a gestire la sua bad attitude, ed il fatto che ci riesca solo con persone che possono influenzare la sua carriera è un puro caso.

3] il capo sprona in questo modo i collaboratori: è noto che lo stress e la competizione estrema giovano al raggiungimento degli obiettivi, quindi ai fini del successo aziendale tiene sempre i sottoposti sul chi vive.

4] il capo è di esempio per i suoi collaboratori, cioè si aspetta che voi gli sorridiate e siate gentili con lui (per sfogare lo stress indotto, potete sempre tirare i cartocci alle donne delle pulizie, o menare i vostri figli).

5] nessuna delle precedenti.

...a proposito

A proposito del primo post di questo blog, voglio aggiungere un'osservazione:
la corretta descrizione del problema nell'opportuno linguaggio (formale) può molto spesso rappresentare la soluzione.
Parliamo di software: i requisiti sono una rappresentazione del problema; ma anche il design è una rappresentazione del problema. Lo è in quanto descrive (in modo dettagliato, si spera) il dominio del problema da risolvere, specificandone gli attori e le relazioni. Dove il documento dei requisiti è una descrizione passiva del problema, il design ne è una descrizione attiva.
Il software emerge da una descrizione (e quindi, da una comprensione) sempre più dettagliata del problema da risolvere.

Ahh, che bel post.

poi mi guardo attorno... Mah!

Non portatemi problemi, portatemi soluzioni!

Immagino che molti si siano trovati nell'imbarazzante situazione in cui il proprio capo pronuncia la fastidiosa ed inopportuna frase "non portatemi problemi, portatemi soluzioni!".

Generalmente ho sempre pensato che la situazione appena descritta qualificasse il capo come un facilone, incapace di cogliere il fastidio dei collaboratori che si sentono rivolgere l'infelice frase fatta.

Con il passare degli anni, però, mi sono reso conto che esiste un'interpretazione della suddetta frase che non è nè frustrante nè ridicola...
Avete presente quando, in un forum tecnico, qualche novellino pone una questione appena meno che ovvia, e si vede rispondere RTFM (read the fucked manual)?
Dopo qualche tempo passato sui forum, si apprende la sana pratica di sbattersi un poco prima di pretendere la pappa pronta, la risposta confezionata sulle nostre esigenze.
Di solito gli esperti tendono a rispondere più spesso (e molto più volentieri) a coloro che dimostrano di aver effettuato qualche ricerca, di aver almeno provato a trovare la risposta da soli.

Dunque, credo che l'interpretazione positiva della fatidica frase del titolo sia appunto questa: il boss vuole che almeno proviate a trovare una strada, e giungiate da lui non per chiedere la panacea, ma per discernere quale sia l'opzione migliore tra la manciata di scelte che avete individuato per affrontare il problema.


PS
...naturalmente quando sui forum trovate un novellino che pretende una risposta rapida e concisa al suo problema senza aver nemmeno provato a risolverselo, potete essere ragionevolmente certi che si tratta di un manager.