Alla ricerca del modo migliore per combinare il refactoring dell'architettura profonda con lo sviluppo basato sulle funzionalità

Naviga le tue risposte
9

Istruzione problema:

Data:

  • TFS come controllo del codice sorgente
  • Applicazione client desktop pesante con tonnellate di codice legacy con o senza design di architettura quasi assente.
  • I client richiedono costantemente nuove funzionalità con una qualità del suono, veloce
    consegna e lamentarsi costantemente per l'utente ostile UI.

Problema:

L'applicazione richiede indubbiamente un profondo refactoring. Questo processo rende inevitabilmente l'applicazione instabile e la fase di stabilizzazione dedicata è necessaria.

Abbiamo provato:

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

Cosa viene consigliato:

Link all'articolo (pdf)
Creare un ulteriore ramo per refactoring (RB) periodicamente sincronizzandolo con MB tramite unione da MB a RB. Dopo che l'RB è 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 qualsiasi FB a MB.

Il vantaggio principale: il master stabile il più delle volte.

Ci sono alternative migliori alle procees?

    
posta Pavel Voronin 19.12.2012 - 21:26
fonte

1 risposta

1

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 mancanza di essa) è il problema principale = > ripensaci
  • di solito ci sono caratteristiche di lavoro, il problema è l'elevato accoppiamento tra le varie parti del progetto; Ho valutato quali sono le funzionalità di lavoro e le ho riutilizzate, ma nella mia architettura

  • parla al 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 raggiunto un accordo per un piano di rilascio:

  • nella fase di fusione delle 2 soluzioni (rendere l'architettura + riutilizzare le funzionalità 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 rilasciate pochissime versioni sul vecchio prodotto. Quindi le cose cambiate sono state facilmente unite nella nuova soluzione.

  • la prima nuova versione (rilascio 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 puoi sfuggire a un (abbastanza breve) periodo di rilasci sporadici. È importante che tu possa essere d'accordo con il tuo cliente.

    
risposta data 20.12.2012 - 10:50
fonte

Leggi altre domande sui tag

Modello di costruzione del menu Utilizzo di un repository Apt per aggiornamenti software a pagamento