Eliminare il codice duplicato: la scelta non è meccanica

 

Scelta la duplicazione da rimuovere e i refactoring da usare capita anche che ci sono più alternative per rimuoverla e quindi bisogna   scegliere il modo di rimuovere la duplicazione 

Per fare un esempio, il metodo   void C { a(); a(); X(); a(); X(); X(); }  può essere  trasformato in
        void C { aa(); X(); a(); XX(); }
oppure in   
    void C { a(); aX(); aX(); X(); }

In questo caso nel cercare un nome per il metodo ottenuto in un modo (nel esempio un nome per aa() e XX()) e quello ottenuto nell'altro (nel esempio u nnome per aX())  scegliere quello col nome che ha più senso aiuta a fare la scelta giusta.

Un altro criterio è quello di pensare ad alcuni scenari possibili di evoluzione del programma e valutare con quale codice le cose andrebbero meglio.  Cioè con quale codice per aggiungere una nuova funzionalità è necessario cambiare meno cose, significa scegliere quella strada che meglio rispetta il principio Open/Closed o PrincipioOCP .

Riferimenti: Working Effectively with legacy code di M.C.Feathers

 

Tags :   |  |  |  |

Print | posted @ Wednesday, August 13, 2008 7:53 PM

Comments on this entry:

Gravatar # re: Eliminare il codice duplicato: la scelta non è meccanica
by LudovicoVan at 8/13/2008 9:55 PM

Se mi consenti un commento en passant, c'e' un problema di fondo: ridondanza *non* e' inutile.

Si potrebbe ovviamente approfondire.

-LV
Gravatar # re: Eliminare il codice duplicato: la scelta non è meccanica
by LudovicoVan at 8/14/2008 6:29 AM

Intendo che una certa dose di ridondanza rende il codice piu' flessibile alle modifiche. Questo si potrebbe rendere matematicamente, ma vale in pratica.

Per cui ok alla rimozione della duplicazione, ma solo di quella "di troppo"...

-LV
Gravatar # re: Eliminare il codice duplicato: la scelta non è meccanica
by LudovicoVan at 8/14/2008 6:57 AM

Per essere piu' specifico, prendo un esempio:

"Un altro criterio è quello di pensare ad alcuni scenari possibili di evoluzione del programma e valutare con quale codice le cose andrebbero meglio."

Qui la rimozione della duplicazione si e' fatta addirittura proattiva (come del resto e' nell'idea di refactoring). Ma lo scenario evolve per salti discontinui, per cui siamo di fatto all'altro capo della banda della flessibilita'.

-LV
Gravatar # re: Eliminare il codice duplicato: la scelta non è meccanica
by LudovicoVan at 8/15/2008 1:00 PM

L'unico "esempio" che conosco in cui si fa (abbastanza) esplicitamente questo discorso ridondanza, e' un caso studio sul mio sito:

http://julio.diegidio.name/CaseStudies/TicTacToe/Docs/TicTacToe.1.2.B.pre/TicTacToe.1.2.B.pre.htm

Comunque, sui requisiti: pensando alla lista su Wikipedia, date in anticipo le opportune avvertenze sul fatto che i requisiti sono specifici al progetto (e quindi intendo che questo concetto deve essere trasmesso prima di iniziare il gioco vero e proprio), si presta moltissimo a fare un gioco a classificare quei requisiti nelle due colonne, funzionali e non-funzionali.

Un esercizio del genere penso che aiutarebbe proprio a dare un senso a parole che prese di per se ne hanno uno e centomila.

-LV
Gravatar # re: Eliminare il codice duplicato: la scelta non è meccanica
by LudovicoVan at 8/15/2008 1:39 PM

Per non far perdere tempo a nessuno:

La parte delle considerazioni "ingegneristiche" non parla di ridondanza e anzi e' messa nei termini a me allora noti, e puo' essere ignorata; la ridondanza e' nel codice sorgente, che si puo' scaricare. Il Controller forse e' l'esempio piu' lampante.

-LV
Gravatar # re: Eliminare il codice duplicato: la scelta non è meccanica
by LudovicoVan at 8/16/2008 4:59 AM

Intendo che una certa dose di ridondanza rende il codice piu' flessibile alle modifiche.

Questo si potrebbe rendere matematicamente, ma vale in pratica, e soprattutto vale a prescindere! Non c'e' un quando/quale/dove.

Comunque, dite la vostra che ho detto la mia.

-LV
Comments have been closed on this topic.