Riutilizzo del codice: riutilizzo del metodo complesso rispetto alle parti che selezionano la ciliegia

5

Attualmente mi trovo di fronte a una situazione in cui non sono abbastanza sicuro di come procedere nel modo migliore.

Sfondo

Sto pianificando un nuovo processo di importazione dei dati, che importerà il personale e il salario informazioni da un file di testo prodotto da un sistema diverso. Noi già avere un processo di importazione per i dati in questione, ma il formato dell'importazione il file cambierà completamente. Pertanto, mentre i dati letti rimangono uguali (nomi dei dipendenti, pagamento voti, pagamenti del salario passato ...), si esprime in modo molto diverso nel nuovo formato di file (formato diverso, campi diversi, diversa codifica dei dati, rappresentazione diversa di casi speciali come il congedo non retribuito o retroattivo cambi di stipendio).

Come riutilizzare?

Ora vorrei riutilizzare il più possibile il codice di importazione esistente. Il il problema è che la maggior parte delle classi e dei metodi esistenti hanno parti che potrebbero essere riutilizzato (principalmente le parti che si occupano di scrivere i dati nel nostro database, che non è cambiato), ma hanno anche molti dettagli sulla vecchia importazione formattare con hardcoded, quindi il riutilizzo diretto è impossibile.

Ora vedo due alternative:

  1. prova a rifattorizzare e rielaborare il codice esistente per essere più indipendente del particolare formato di importazione, quindi può gestire sia vecchi che nuovi formato
  2. seleziona le parti del vecchio codice che si applica ancora (estrarli separare metodi o simili) e riutilizzare

Il mio problema

Sto trovando difficile giudicare quale sia l'approccio migliore. Da un lato, io credo che il riutilizzo sia importante, e 1) sembra permettermi di riutilizzare di più. Sul Dall'altro lato, guardando attraverso il codice ho almeno una sensazione istintiva Il 30% -50% del codice non viene più applicato, quindi temo che 1) potrebbe essere molto lavori di refactoring, e alla fine mi piacerebbe riutilizzare solo più che con approccio 2).

Il problema è (sento) che dovrò decidere in anticipo, perché è così difficile da cambiare approccio una volta iniziato: se inizio con 1) e dopo alcuni giorni di refactoring trovo che la piccola "carne" reale rimane nel funzioni generalizzate, devo buttar via tutti i refactoring e iniziare di nuovo con un codice separato che chiama il vecchio codice quando necessario.

Quindi, come risolvete i nuovi problemi quando avete un codice che è molto simile, ma differisce in molti dettagli per ciò che vi serve? Come giudichi quale approccio al riutilizzo del codice ha più senso?

    
posta sleske 27.05.2011 - 13:11
fonte

6 risposte

6

Quindi hai un vecchio processo di importazione e ne hai bisogno uno nuovo, per un diverso formato di dati. Il vecchio codice non è disaccoppiato dal formato di input esatto.

Il mio consiglio è di iniziare da zero e copiare e incollare qualsiasi parte sia utile. Assicurati che il tuo nuovo codice disaccoppia la funzione di input e output e abbia solidi casi di test per entrambi. Quindi, la prossima volta che tu o il tuo successore hai bisogno di una funzione simile, sarà molto più facile riutilizzare il codice. Se possibile, utilizza il vecchio codice per creare un filtro di input per il vecchio formato, testando il tuo disaccoppiamento.

Il riutilizzo del codice è una grande idea, ma riusare le decisioni sbagliate non tanto.

    
risposta data 27.05.2011 - 13:50
fonte
4

Per iniziare a rispondere al problema, questo è quello che credo possa essere la tua soluzione. Il sistema avrebbe tre parti funzionali. La parte centrale sarebbe una (ragionevolmente astratta) nella rappresentazione della memoria dei dati. La seconda parte sarebbe la logica di output che sarebbe in grado di inviare i dati al database. Il terzo (e più rilevante in questo caso) sarebbe la logica di input.

La logica di input legge il file e crea la rappresentazione in memoria. Questa parte dipende dal framework di input. Potrebbe esserci un framework di analisi coinvolto (se il formato è abbastanza complesso da meritarlo), che potrebbe essere riutilizzato, ma altrimenti questa parte dovrebbe essere riscritta.

Quello che dovresti fare dipende dal tuo codice esistente. Se si tratta di un grosso spaghetto che è quasi impossibile rifattorizzare in un tale framework (possibilmente con un codice di utilità di analisi), allora probabilmente dovresti fare una riscrittura e selezionare ciò che è salvabile. Se il refactoring può funzionare, fallo e, come ulteriore vantaggio, il tuo programma ora può gestire entrambi i formati di input allo stesso tempo e in un modo che rende abbastanza semplice aggiungere un altro formato.

    
risposta data 27.05.2011 - 15:13
fonte
3

Il mio consiglio è di non esagerare con il riutilizzo del codice. A volte (più spesso di quanto pensi) pensi di dover riutilizzare il codice in un posto nuovo, ma in realtà è solo qui e ora che il codice di cui hai bisogno è uguale al codice che hai a disposizione nella parte più vecchia del sistema. Se due componenti sono accoppiati logicamente e si svilupperanno insieme (ad esempio, varianti diverse dello stesso problema aziendale), di solito è bene fare qualche sforzo per riutilizzare il codice. Se si presentano per sbaglio solo in modo simile, appartengono a due diversi domini problematici e potrebbero svilupparsi lungo percorsi diversi in futuro, accoppiandoli tramite il riutilizzo del codice si porteranno più problemi che benefici. In questa situazione, non esitare a Ctrl + C, Ctrl + V.

    
risposta data 27.05.2011 - 13:46
fonte
1

Perché non scrivi semplicemente qualcosa per riformattare i nuovi dati nel formato di input esistente che sai già funziona?

    
risposta data 27.05.2011 - 15:28
fonte
1

Vado a dire con l'opzione n. 1, ma avvicinati come se fosse l'opzione n. Scrivi da zero un sistema completamente nuovo e copia le parti buone della vecchia base di codice. Come qualcuno ha già menzionato, rendere il formato di input / output collegabile. Quindi scrivi il tuo nuovo formato di input / output.

E poi, scrivi un formato di input / output per il tuo formato OLD. Ecco. Hai l'opzione n. 1 completa. La cosa bella di farlo in questo modo è che puoi saltare l'ultimo passaggio (porting vecchio formato dati) se sei allungato per tempo.

    
risposta data 27.05.2011 - 16:02
fonte
1

Raccomando di refactoring il codice. Essenzialmente hai due formati di input che devi affrontare e cambia l'abitudine di essere costante, ci saranno probabilmente nuovi formati in futuro. Ci sono un paio di modi per organizzare il codice di destinazione.

  1. Refactor e sposta la logica aziendale in un insieme di funzioni di utilità. Ciò mantiene i bit riutilizzabili disponibili per entrambi i formati di file e, a seconda di quanto semplici / rigidi siano i bit riutilizzabili, può essere la soluzione più rapida. Funziona meglio se ogni funzione opera direttamente sui dati forniti. Se è necessario fare riferimento a dati in un'altra parte del file, potrebbe essere necessario guardare l'opzione 2.

  2. Refactor per separare l'analisi e il consumo di dati. In altre parole, avere una rappresentazione interna dei dati che non cambierà se non si hanno nuovi requisiti. Questo può contenere i bit riutilizzabili, quindi è possibile gestire la logica più complessa basata sui dati in diverse parti della gerarchia degli oggetti. I due input si limitano a consumare il formato raw e convertirlo nella rappresentazione interna. Per supportare nuovi formati, è sufficiente aggiungere un nuovo parser front-end.

NOTA: solo refactoring ciò che è necessario per il nuovo formato di input. Ciò riduce al minimo il sovraccarico di refactoring e ti consente di concentrarti su ciò che è importante per il nuovo formato.

    
risposta data 27.05.2011 - 17:14
fonte

Leggi altre domande sui tag