Alla ricerca del modo migliore per combinare il refactoring di architettura profonda con lo sviluppo basato su funzionalità

Dichiarazione problema:

Dato:

TFS come controllo del codice sorgente
Applicazione client desktop pesante con tonnellate di codice legacy con progettazione dell'architettura difettosa o quasi assente.
I clienti che richiedono costantemente nuove funzionalità con qualità del suono,
consegna rapida e lamentano costantemente un'interfaccia utente ostile.

Problema:

L'applicazione richiede senza dubbio un profondo refactoring. Questo processo rende inevitabilmente l'applicazione instabile ed è necessaria una fase di stabilizzazione dedicata.

Abbiamo provato:

Refactoring in master con fusioni periodiche da master (MB) a feature branch (FB). (errore mio) Risultato: molti rami instabili.

Cosa ci viene consigliato:

Link all'articolo (pdf)
Crea periodicamente un ramo aggiuntivo per refactoring (RB) sincronizzandolo periodicamente con MB tramite l'unione da MB a RB. Dopo che RB si è stabilizzato, sostituiamo il master con RB e creiamo un nuovo ramo per ulteriori refactoring. Questo è il piano Ma qui mi aspetto il vero inferno di unire MB a RB dopo aver unito tutti gli FB a MB.

Il vantaggio principale: padrone stabile per la maggior parte del tempo.

Ci sono alternative migliori ai processi?

development-process refactoring

— Pavel Voronin
fonte

Possibili miglioramenti (piuttosto che alternative) al processo proposto: lo strumento di unione TFS è piuttosto ingombrante rispetto a varie utilità alternative diff. Se non lo si è già fatto, è possibile che l'unione manuale sia meno dolorosa se si configura il client TFS per utilizzare un'utilità diff migliore, piuttosto che lo strumento integrato. Potresti anche trovare utile l'utilità Microsoft Power Tools TFS. Offre la possibilità di eseguire una diff tra changeset o branch, piuttosto che solo tra singoli file.

— Brian,

Ho avuto una situazione simile in passato. Cosa ho fatto:

valutare lo stato attuale del progetto; nella maggior parte delle situazioni l'architettura (o la sua mancanza) è il problema principale => ripensarci
di solito ci sono funzionalità funzionanti, il problema è l'elevato accoppiamento tra le varie parti del progetto; Ho valutato quali sono le caratteristiche di lavoro e le ho riutilizzate, ma nella mia architettura
parlare con il cliente; Non so cosa dice il tuo manager, ma penso che sia importante parlare con il cliente ed essere sincero; ha bisogno di sapere che stai lavorando sulla qualità del suo prodotto. Ho fatto un accordo per un piano di rilascio:
nella fase di fusione delle 2 soluzioni (rendere l'architettura + funzionalità di riutilizzo dal vecchio progetto) le uniche cose che sono state rilasciate (nuove funzionalità) sono state fatte sul vecchio prodotto; tuttavia, le nuove versioni contenevano solo importanti correzioni di bug. Quindi sono state fatte pochissime versioni sul vecchio prodotto. Quindi le cose cambiate sono state facilmente fuse nella nuova soluzione.
la prima nuova versione (versione del nuovo prodotto) conteneva solo ciò che conteneva il vecchio prodotto (nessuna nuova funzionalità); dopo averlo stabilizzato (la stabilizzazione non ha richiesto molto tempo) ho lavorato con un singolo progetto

Penso che non si possa sfuggire a un periodo (ragionevolmente breve) di pubblicazioni sporadiche. È importante che tu possa essere d'accordo con il tuo cliente.

— Paul Ianas
fonte