Come eseguire il refactoring su generici dalla classe che eredita da CollectionBase?

Question

Sto lavorando su un'applicazione che contiene circa 250.000 righe di codice.Attualmente sono l'unico sviluppatore che lavora su questa applicazione originariamente creata in .NET 1.1.Pervasiva ovunque è una classe che eredita da CollectionBase.Tutte le raccolte di database ereditano da questa classe.Sto invece valutando la possibilità di refactoring per ereditare dalla raccolta generica List.Inutile dire che il libro Refactoring di Martin Fowler non contiene suggerimenti.Dovrei tentare questo refactoring?In tal caso, qual è il modo migliore per affrontare questo refactoring?

E sì, ci sono test unitari ovunque, ma nessun team di QA.

Answer 1

250.000 righe sono molte da rifattorizzare, inoltre dovresti prendere in considerazione alcuni dei seguenti elementi:

1. Disponi di un reparto QA che sarà in grado di eseguire il QA del codice rifattorizzato?
2. Hai test unitari per il vecchio codice?
3. Esiste un arco temporale attorno al progetto, ad es.stai mantenendo il codice poiché gli utenti trovano bug?

se rispondessi 1 e 2 no, scriverei innanzitutto unit test per il codice esistente.Rendili estesi e approfonditi.Una volta che li hai installati, crea una versione e avvia il refactoring.I test unitari dovrebbero essere in grado di aiutarti a eseguire correttamente il refactoring dei generici.

Se 2 è sì, basta eseguire il branch e avviare il refactoring, facendo affidamento su tali test unitari.

Anche un dipartimento di controllo qualità sarebbe di grande aiuto, dal momento che puoi inviare loro il nuovo codice da testare.

E infine, se i clienti/utenti necessitano di correzione di bug, correggili prima.

Answer 2

Non.A meno che tu non abbia un'ottima giustificazione commerciale per sottoporre il tuo codice base a questo esercizio.Qual è il risparmio sui costi o i ricavi generati dal refactoring?Se fossi il tuo manager probabilmente lo sconsiglierei.Scusa.

Answer 3

Quanto è esposto CollectionBase dalla classe ereditata?
Ci sono cose che Generics potrebbe fare meglio di CollectionBase?

Voglio dire, questa classe è molto utilizzata, ma è solo una classe.La chiave del refactoring è non disturbare lo status quo del programma.La classe dovrebbe sempre mantenere il suo contratto con il mondo esterno.Se riesci a farlo, non stai facendo il refactoring di un quarto di milione di righe di codice, ma forse solo 2500 (ipotesi casuale, non ho idea di quanto sia grande questa classe).

Ma se c’è molta esposizione da questa classe, potresti dover trattare quell’esposizione come un contratto e provare a fattorizzare l’esposizione.

Answer 4

Se tu Sono andrò fino in fondo, non usarlo Elenco< T >.Invece, usa System.Collections.ObjectModel.Collezione< T >, che è più un successore spirituale di CollectionBase.

IL Collection<T> La classe fornisce metodi protetti che possono essere utilizzati per personalizzare il proprio comportamento quando si aggiungono e rimuovono elementi, si cancella la raccolta o si imposta il valore di un elemento esistente.Se usi List<T> non c'è modo di sovrascrivere il file Add() metodo da gestire quando qualcuno inserisce un annuncio nella raccolta.

Answer 5

Penso che il refactoring e il mantenimento del codice aggiornato siano un processo molto importante per evitare la putrefazione/l'odore del codice.Molti sviluppatori soffrono di essere sposati con il proprio codice o semplicemente di non essere abbastanza sicuri nei test unitari per essere in grado di fare a pezzi le cose, ripulirle e farlo bene.

Se non ti prendi il tempo per ripulirlo e migliorare il codice, a lungo termine te ne pentirai perché dovrai mantenere quel codice per molti anni a venire, altrimenti chiunque ne prenderà il controllo ti odierà.Hai detto che hai test unitari e dovresti essere in grado di fidarti di questi test per assicurarti che quando esegui il refactoring del codice funzionerà ancora.

Quindi dico di farlo, ripulirlo, renderlo bello.Se non sei sicuro che i tuoi test unitari possano gestire il refactoring, scrivi altro.

Answer 6

Sono d'accordo con Tommaso.

Sento la domanda che dovresti sempre porre quando il refactoring è "Cosa guadagno facendo questo vs facendo qualcos'altro con il mio tempo?" La risposta può essere molte cose, dall'aumento della manutenibilità a prestazioni migliori, ma arriverà sempre a spese di qualcos'altro.

Senza vedere il codice è difficile per me dirlo, ma sembra una brutta situazione in cui eseguire il refactoring.I test sono utili, ma non sono infallibili.Basta che uno di loro abbia un presupposto errato e il tuo refactoring potrebbe introdurre un brutto bug.E senza il QA per rilevarlo, non sarebbe positivo.

Personalmente sono anche un po' diffidente nei confronti di enormi refactoring come questo.Mi è costato un lavoro una volta.Era il mio primo lavoro al di fuori del governo (che tende ad essere un po' più indulgente, una volta ottenuto il "mandato" è dannatamente difficile essere licenziato) ed ero l'unico programmatore web.Mi è caduta in grembo un'app ASP legacy scritta male.La mia prima priorità era trasformare quella dannata cosa in qualcosa di meno... schifoso.Il mio datore di lavoro voleva che gli incendi fossero spenti e niente di più.Sei mesi dopo stavo di nuovo cercando lavoro :p Morale di questa storia:Consulta il tuo manager prima di intraprendere questa attività.