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.