Revisione del progetto per il refactoring di una funzione di grandi dimensioni

0

Terminologia di base:
Report - report singolo da generare
ReportGroup - gruppo di Report (s) da generare
Request - contiene uno o più ReportGroup

Sto lavorando al refactoring della grande funzione (~ 350 linee) in una classe ancora più grande (~ 2500 linee)
La funzione è responsabile di una generazione di report in vari formati (txt, csv, xlsx, pdf, zip)
Attualmente, la funzione supporta l'estrazione per un singolo Report o singolo ReportGroup . Il mio compito è estendere la funzione per supportare l'estrazione per più ReportGroup s.

Questa funzione è essenzialmente una serie di passaggi che alla fine generano un file nel formato richiesto.
Di seguito sono riportati i passaggi che è possibile identificare per un singolo report:

  1. Analizza / Convalida l'input: restituisce se non è valido.
  2. Ottieni risultato (nella forma di un albero) - restituisce se non è valido.
  3. Crea ResultDescriptor - Poco contenente il risultato dell'albero e aggiuntivo i metadati calcolano dalle proprietà di richiesta e risultato.
  4. Crea GenerationResultStatus e aggiungilo all'oggetto Response
  5. Passare il descrittore del risultato al motore di rendering e ottenere il percorso file indietro.
  6. Sposta il file generato nella posizione condivisa (la posizione viene determinata in base sulle proprietà ResultDescriptor ).
  7. Genera Response oggetto contenente la posizione del file del risultato finale, GenerationResultStatus , overallstatus (bool) e messaggio di errore e restituirlo al chiamante.

Ho trovato le seguenti classi:
Attori di generazione di report singoli:

ResultDescriptorBuilder
GenerationResultStatusBuilder
StandartizedFileMover
ResponseBuilder


Generatori di rapporti:

SingleReportGenerator : elabora un singolo report e genera un singolo file, GroupedReportGenerator - Decoratore su SingleReportGenerator . Elabora il gruppo di report e genera un singolo file (xlsx, pdf).
ZipedReportGenerator - Decoratore su SingleReportGenerator . Elabora il gruppo di report e genera un singolo file zip.
GroupOfGroupedReportGeneratorPdf - Decoratore su GroupedReportGenerator . Elabora l'intera richiesta eseguendo il looping di ogni ReportGroup e passando a GroupedReportGenerator .
I file risultanti vengono quindi uniti in un unico pdf. Supporta solo il formato pdf.

Suppongo che la domanda più importante sia che dovrei anche preoccuparmi di fare il refactoring (da un punto di vista puramente pratico)?
Probabilmente potrei andare via con una patch che chiama la funzione corrente in un ciclo e quindi unisce i risultati.
La funzione non cambia molto spesso e non prevedo nuove modifiche.
Ho alcuni test di unità e integrazione, ma sono piuttosto semplici e non offrono una copertura completa.

Nel caso in cui decida di andare con il refactoring, ci sono problemi che ho trascurato?
Esiste uno schema di progettazione che può renderlo più generico?
Qualsiasi suggerimento di denominazione è benvenuto. Penso di esagerare con le parole di Generatore / Costruttore.

    
posta DanielS 06.06.2015 - 21:08
fonte

1 risposta

1

Il tuo modo di pensare è perfettamente ragionevole.

I guess, the biggest question is should I even bother doing the refactoring (from a purely practical point of view)?

Questo dipende. Dal punto di vista dell'artista, la risposta è . Ma ci sono soldi coinvolti. Pertanto, è necessario stimare l'impatto del codice non rifatto sul ciclo di sviluppo. Se causerà difficoltà o danneggerà in qualche modo la progettazione del sistema, la risposta sarà di nuovo SI.

I could probably get away with a patch that calls current function in a loop and then merges the results.

Probabilmente. In realtà, ciò renderebbe un po 'di facciata il codice attuale, che nasconderà solo un brutto pezzo di esso;)

In case I do decide to go with the refactoring, Are there any issues I overlooked? Is there a design pattern that can make this more generic?

Io non la penso così

    
risposta data 07.06.2015 - 19:43
fonte

Leggi altre domande sui tag