Risoluzione dei conflitti di unione dovuti al refactoring

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

Come si gestiscono i conflitti di unione che si sono verificati a causa del fatto che qualcuno ha effettuato un refactoring di una parte del codice, mentre qualcun altro stava lavorando a una funzione per lo stesso pezzo di codice?

Fondamentalmente, non ho idea di come gestirlo in modo efficiente. Ci sono delle migliori pratiche da seguire al riguardo? C'è qualche differenza su come si dovrebbe gestire questo per un sistema con tonnellate di codice legacy?

Buona domanda. La migliore strategia che mi viene in mente è:

Prevenzione

Una combinazione di integrazione continua e spesso piccole rifatturazioni (anziché occasionali grandi rifatturazioni) contribuirà notevolmente a ridurre al minimo i costi e la frequenza di tali conflitti.

Penso che per rispondere alla tua domanda, prima dobbiamo vedere perché si verificano i conflitti 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 allo stesso tempo e poi entrambi tenta di archiviare. Il primo sviluppatore non otterrà alcun conflitto, naturalmente. Ma il secondo (terzo, quarto e così via) avrebbe avuto conflitti. Perché, perché ha un codice che è parzialmente o completamente diverso dal codice esistente sul server.

Questo in natura significa che il secondo sviluppatore ha in mente qualcosa di diverso rispetto al primo sviluppatore. Questa differenza può variare a seconda dello stile, come l'utilizzo new UserManager().GetUserName()anziché UserManager userManager = new UserManager(); userManager.GetUserName();fino al livello menzionato, il che significa che entrambi gli sviluppatori hanno avuto idee diverse su come riformattare il codice per migliorarlo.

La fusione, d'altra parte, non significa che gli sviluppatori possano archiviare il loro codice senza considerare i conflitti. Essi dovrebbero e devono affrontare questi conflitti. Se i conflitti non sono importanti, possono archiviare 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 coordinarsi insieme per effettuare il check-in della soluzione migliore.

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

Non concordo sulla prevenzione di queste circostanze, poiché dovremmo essere più reali che teorici. A volte un ragazzo è davvero bravo in CSS, mentre un altro è davvero bravo in ASP.NET Markup. Ma il loro lavoro potrebbe essere in conflitto quando entrambi dovrebbero lavorare sulla pagina di accesso per farlo funzionare. Voglio dire, se pensiamo reale (non ideale), possiamo vedere che molte volte questo fenomeno (conflitto) si verifica.

Un altro punto che volevo solo menzionare è quello di utilizzare gli strumenti per aiutarti nel processo di check-in. Questi strumenti di solito visualizzano la differenza tra il codice del server e il codice dello sviluppatore e aiutano molto a determinare quale parte deve essere archiviata.

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

Se, tuttavia, hai una riunione quotidiana o un manager , non puoi avere questo problema.

Parla (tramite uno stand up quotidiano) o parla con un manager.

Ciò è banalmente prevenuto parlando.

Avere un ramo comune separato per lo sviluppo di una determinata funzione, unire / tirare / spingere spesso - tutto qui.

E comunicare . Parla con altri sviluppatori del codice anche al momento del lancio. Anche durante la codifica)))

Assicurarsi che l'unione sia il più semplice possibile. Il refactoring è di solito un processo piuttosto meccanico che modifica molte linee esistenti : sposta dichiarazioni variabili, cambiamenti di spazi bianchi, formattazione, sequenza di operazioni. La creazione di funzionalità è in genere un'iniziativa molto più creativa, che spesso porta a un nuovo codice più alcune piccole modifiche 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à aggiuntiva anziché viceversa. Sulla base di questo, direi che come regola generale è necessario applicare prima le modifiche più complesse, seguite da modifiche progressivamente più semplici.