Risoluzione dei conflitti di fusione dovuti al refactoring

13

Recentemente sono stato coinvolto in una discussione su come gestire il refactoring in generale (che è di per sé un argomento interessante). Alla fine è stata sollevata la seguente domanda:

In che modo un handle gestisce i conflitti che si sono verificati a causa del fatto che qualcuno ha eseguito il refactoring di una parte del codice, mentre qualcun altro stava lavorando su una funzione per lo stesso pezzo di codice?

Fondamentalmente, non ho idea di come affrontarlo in modo efficiente. Ci sono delle migliori pratiche che si dovrebbero seguire per quanto riguarda questo? C'è qualche differenza su come si dovrebbe gestire questo per un sistema con tonnellate di codice legacy?

    
posta Andreas Johansson 16.09.2011 - 12:39
fonte

5 risposte

9

Buona domanda. La migliore strategia che posso pensare è:

Prevenzione

Una combinazione di integrazione continua e realizzazione di piccoli refactoring spesso (anziché refettori occasionali di grandi dimensioni) contribuirà notevolmente a ridurre al minimo i costi e la frequenza di tali conflitti.

    
risposta data 16.09.2011 - 12:47
fonte
3

Penso che per rispondere alla tua domanda, prima dobbiamo capire perché i conflitti si verificano, e qual è il vero significato e il processo di fusione?

I conflitti si verificano solo quando due o più sviluppatori stanno lavorando sullo stesso file alla stessa ora e quindi entrambi cercano di registrarsi. Il primo sviluppatore non ottenere qualsiasi conflitto, ovviamente. Ma il secondo (terzo, quarto e così via) otterrebbe conflitti. Perché, perché (s) ha un codice che è parzialmente o completamente diverso dal codice esistente sul server.

Questo in natura significa che il secondo sviluppatore ha qualcosa in mente diverso dal primo sviluppatore. Questa differenza può variare rispetto allo stile, ad esempio utilizzando new UserManager().GetUserName() anziché UserManager userManager = new UserManager(); userManager.GetUserName(); fino al livello che hai menzionato, il che significa che entrambi gli sviluppatori avevano idee diverse su come rifattorare il codice per migliorarlo.

L'unione, d'altra parte, non significa che gli sviluppatori possano effettuare il check-in del loro codice senza considerare i conflitti. Loro dovrebbero e devono indirizzare tali conflitti. Se i conflitti non sono importanti, allora possono effettuare il check-in e sovrascrivere il codice precedente. Ma quando vedono qualcosa di completamente diverso, dovrebbero chiamare lo sviluppatore precedente e parlare con lui, in modo che entrambi possano essere coordinati insieme per il check-in nella soluzione migliore.

Ad esempio, se chiedi a due sviluppatori di migliorare la biblioteca di pagamento online e il loro lavoro si sovrappone, ciò significa che almeno in alcuni punti ci sono 2 soluzioni diverse. Quindi, una di queste soluzioni dovrebbe essere discussa e accettata, quindi verificata, come soluzione migliore.

Non sono d'accordo su prevenire queste circostanze, poiché dovremmo tendenzialmente essere più reali che teorici. A volte un ragazzo è davvero bravo con i CSS, mentre un altro è molto bravo con ASP.NET Markup. Ma il loro lavoro potrebbe entrare in conflitto quando entrambi dovrebbero lavorare sulla pagina di login per farlo funzionare. Voglio dire, se pensiamo reale (non ideale), possiamo vedere che molte volte questo fenomeno (conflitto) accade.

Un altro punto che volevo menzionare, è utilizzare gli strumenti per aiutarti nella procedura di check-in. Questi strumenti di solito visualizzano la differenza tra codice server e codice sviluppatore e aiutano molto a determinare quale parte deve essere archiviata.

    
risposta data 16.09.2011 - 12:50
fonte
3

Se non esiste una gestione attiva delle attività, esistono conflitti.

Se, tuttavia, hai un incontro giornaliero in piedi o un gestore , non puoi avere questo problema.

O parlare (tramite un quotidiano alzarsi in piedi) o parlare con un manager.

Questo è banalmente impedito parlando.

    
risposta data 16.09.2011 - 13:53
fonte
1

Avere un ramo comune separato per lo sviluppo di una determinata funzione, unire / tirare / spingere spesso - il gioco è fatto.

E comunicare . Parla con altri sviluppatori del codice anche al momento del lancio. Anche quando si scrive codice)))

    
risposta data 16.09.2011 - 12:45
fonte
1

Assicurati che l'unione sia il più semplice possibile. Refactoring di solito è un processo piuttosto meccanico che modifica molte linee esistenti : sposta dichiarazioni di variabili, cambi di spazi bianchi, formattazione, sequenza di operazioni. La creazione di feature di solito è un'impresa molto più creativa, spesso risultante in nuovo codice più alcune modifiche minori al codice esistente. Ora, se lo sviluppatore che esegue il refactoring registra i passaggi (ad esempio come espressioni regolari), può essere molto più semplice applicarli al codice con la funzionalità extra piuttosto che il contrario. Basandomi su questo, direi che come regola generale devi applicare prima le modifiche più complesse, seguite da modifiche progressivamente più semplici.

    
risposta data 16.09.2011 - 13:10
fonte

Leggi altre domande sui tag