AntonioGanci

# re: Object-Oriented Reengineering Patterns

l'ho sfogliato e l'ho trovato molto interessante

il capitolo 8 sui modi automatici di individuare codice duplicato l'ho trovato interessante, mi chiedo se ci sono tool .NET di questo tipo

il capitolo 10 sulla eliminazione degli if duplicati o evitabili è sempre interessante

il capitolo 2 mi ricorda molto il copione che seguiamo nel planning (degli interventi sul codice) in team prima di affrontare una user story


una considerazione, il libro parla di software redesign. lo scopo del disegno è rendere una applicazione facile da evolvere e modificare:
- ha senso distinguere il design dal redesign ?
- imparare il design non dovrebbe significare imparare a fare redesign cominciando con applicazioni legacy ?

# Libro: Object-Oriented Reengineering Patterns

Libro: Object-Oriented Reengineering Patterns

# re: Object-Oriented Reengineering Patterns

Luka: Per .NET ho visto che c'è http://www.jetbrains.com/teamcity/features/code_quality.html ma non l'ho mai provato e non ti so dire.

> una considerazione, il libro parla di software redesign. lo scopo del disegno è rendere una applicazione facile da evolvere e modificare:
- ha senso distinguere il design dal redesign ?
- imparare il design non dovrebbe significare imparare a fare redesign cominciando con applicazioni legacy ?

Ciò che mi è piaciuto è l'approccio scientifico al reverse engineering su cui non ho visto molti testi e poi anche sul forward engineering.
Spesso i testi di OO/Patterns si focalizzano su un mondo "ideale" in cui dobbiamo modellare tutto da zero, mentre nella realtà questo è piuttosto raro.

# re: Object-Oriented Reengineering Patterns

Colgo un invito da Luca: http://blogs.ugidotnet.org/luKa/archive/2008/06/10/92989.aspx

> lo scopo del disegno è rendere una applicazione facile da evolvere e modificare:

A mio avviso non coglie la generalita' del concetto di design, oltre al fatto che lo scopo, al solito, sarebbe quello di risolvere un certo problema qui e adesso, il resto viene in piu'.

Personalmente, disegno per documentare aspetti dell'implementazione che sono troppo complessi da mettermi semplicemente li' a scrivere codice. Iin realta', piu' agile: mi metto a scrivere codice se l'analisi e' sufficiente; dopodiche', se mi si incasina il cervello su qualcosa di particolare, mi fermo e la disegno.

> ha senso distinguere il design dal redesign ?

Cos'e' il "redesign"?

Se intendiamo, come dice Antonio, forward and reverse engineering (btw, e poi dove lo mettiamo il TDD?), allora gli approcci sono abbastanza diversi (modellare da zero e' diverso da modellare un prodotto legacy per poterci rimettere le mani sopra). Tant'e' che il reverse-engineering ce l'ha una sua letteratura specifica, ma nelle pubblicazioni di stampo ingegneristico generale: viene considerato il passo successivo al Total Quality classico. e le principali differenze, se non ricordo troppo male, sono: TQ punta al miglioramento graduale e continuo, RE punta al salto di qualita' deciso focalizzato ai processi core e/o a maggior valore aziendale (insomma, i processi strategici). RE ha un alto livello di rischio intrinseco, per lo piu' legato all'impatto "culturale" dell'innovazione (principalmente quella di processo), mentre TQ ha un basso rischio e basso impatto, tuttavia e' anche a bassa (se non nulla) efficacia. Entrambi pero' condividono una revisione decisa sia del modo di concepire l'organizzazione aziendale (per processi piuttosto che per funzioni), cosi' come entrambi valorizzano al massimo il contributo delle singole persone al successo complessivo, ma anche la responsabilita' che un tale riconoscimento di valore e ruolo comporta (chi se la sente di fermare la catena? e chi ne ha voglia?).

"Redesign" potrebbe anche voler dire "ristrutturazione" (che non ha niente a che fare con "refactoring").Per me ristrutturazione (restructuring) e' un tipo particolare di forward-engineering.

> imparare il design non dovrebbe significare imparare a fare redesign cominciando con applicazioni legacy ?

Personalmente, direi proprio di no. Sono piu' che simmetrici: il reverse engineering e', a suo modo, un superset del forward engineering...

-LV

# re: Object-Oriented Reengineering Patterns

Scusate, mi si e' un po' incasinato il cervello in effetti.

Il discorso sopra, su Reverse Engineering (RE), sarebbe stato piu' appropriato se fatto in termini di Business Process Reengineering (BPR). La sostanza del discorso tuttavia, e l'idea dietro al RE, credo che restino le stesse...

-LV

# re: Object-Oriented Reengineering Patterns

- btw, e poi dove lo mettiamo il TDD?
in questo caso chiaramente l'approccio TDD è impensabile.

# re: Object-Oriented Reengineering Patterns

Nice, sei quasi piu' drastico di me in questo caso!

:) -LV