02 ott 2008

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.