Come refactoring in un ramo senza perdere la testa?

Question

Rifattorizzo sempre il mio codice e quello degli altri . Quando lavoro in una succursale e non in Trunk, a volte ciò provoca alcune fusioni estremamente dolorose, specialmente se non mi unisco regolarmente a Trunk (il codice della succursale si sposta lentamente dal Trunc e quando le persone modificano Trunk I devi capire manualmente come applicare questo al ramo).

Le soluzioni che conosco sono

1. Unisci costantemente da e verso Trunk: riduce le fusioni dolorose, ma allora perché lavorare in un ramo?
2. Ogni volta che devi refactificare qualcosa, passa a Trunk, esegui il refactoring lì ed entra nel tuo ramo - non lo trovo molto pratico, dal momento che il costo effettivo di cambiare ambiente per ogni refactoring è enorme.

Cosa fai?

Answer 1

Il refactoring su larga scala deve essere eseguito al momento giusto nella sequenza temporale di sviluppo. Se esegui enormi quantità di refactoring in fase di rilascio finirai per farti del male perché introduci dolorose fusioni in un momento in cui i cambiamenti dovrebbero essere ridotti al minimo. Quanto più dirompente sarà il tuo refactoring, tanto prima dovrebbe accadere nel ciclo di sviluppo (e tanto più dovrebbe esserci un processo speciale per esso, ad esempio interrompere il più possibile le modifiche ai file interessati per un periodo di tempo).

La costante fusione da e verso il tronco è generalmente una buona pratica.

Perché lavorare in un ramo in quel caso? Perché hai più controllo (puoi interrompere l'unione nel trunk per stabilizzarlo per il rilascio, ad esempio, senza interrompere i check-in nel tuo ramo di sviluppo). Perché puoi mettere un alto livello di validazione attorno alla fusione da / verso trunk senza influire molto sulla velocità di checkin al ramo di sviluppo.

Answer 2

Vado con 1, faccio piccole modifiche quando possibile e controllo spesso oppure le fusioni diventano dolorose. Avere un ramo separato può semplificare le cose se devi lavorare su altre cose contemporaneamente o se il refactoring richiede più tempo di quanto pensassi inizialmente. L'altro vantaggio è che rende più semplice la partecipazione di più persone al re-factoring e puoi controllare le cose nella filiale tutte le volte che vuoi.

Answer 3

Suggerirei la seguente strategia per scenari in cui l'intervallo di tempo tra le versioni è di almeno 2 mesi.

Quando inizi ad avvicinarti a una versione, crea un ramo di versione. Il ramo di rilascio deve essere trattato come nessun refactoring qui per favore e sono (quasi) ramo completo . È a questo punto che dovresti iniziare a concentrare i tuoi sforzi sulla stabilizzazione della versione sul ramo di rilascio . Unire eventuali correzioni di errori dal ramo di rilascio sul bagagliaio, se necessario. Nel frattempo il tronco viene trattato come perpetuamente aperto per il refactoring . Inoltre, se possibile, cerca di ridurre il refactoring man mano che ti avvicini a un rilascio importante e lo acceleri nei giorni immediatamente successivi.

Nel caso in cui si stia seguendo una strategia di rilascio continuo (ad es. un rilascio ogni 1-2 settimane), non è necessario separare refactoring e codifica su rami separati, a meno che non si stia eseguendo un importante miglioramento chirurgico. In tali situazioni di miglioramento chirurgico (che devono essere distanziate non meno di 3 mesi ciascuna), rilasciare un rilascio dal programma in anticipo ogni volta che si intende eseguire un'unione, utilizzare uno dei cicli per l'unione del rilascio e un aumento dei test, mantenere il incrociamo le dita e poi rilasciamo.

Answer 4

Le modifiche devono essere veloci (quindi non troppe modifiche sotto di te) oppure locali (quindi ti preoccupi solo delle modifiche in un numero limitato di posti).

Altrimenti l'unione può essere tanto lavoro quanto il refactor. Come algoritmo, il blocco ottimistico semplicemente non funziona quando troppe transazioni falliscono e devono essere riavviate.

Fondamentalmente, non puoi permettere una situazione in cui 20 programmatori in un'azienda cambiano tutti i nomi del 50% dei metodi nella base di codice ogni giorno. E del resto, se più persone eseguono sempre il refactoring negli stessi luoghi contemporaneamente, si annullano comunque il lavoro reciproco.

Se i programmatori impiegano molto tempo a supervisionare manualmente le fusioni, allora offri ai tuoi manager l'opportunità di aumentare la produttività modificando il modo in cui le attività vengono definite e assegnate.

Inoltre, "refactoring l'intero sistema per utilizzare le fabbriche ovunque" non è un compito. " Rifattorizza questa interfaccia e le sue implementazioni per utilizzare le fabbriche " è un compito.

Answer 5

Qui eccelle un buon VCS distribuito. Ma suppongo che tu sia già impegnato in SVN.

Personalmente, faccio semplicemente il refactor e poi mi unisco il prima possibile per evitare l'inferno del conflitto. Non è il metodo più produttivo, ma il minimo soggetto a errori.

Una volta ho avuto un ramo che è rimasto inattivo per circa 3 settimane perché la funzione era stata "messa in attesa" ed era impossibile fondersi. Ho appena riavviato la funzione in un nuovo ramo, usando il vecchio come riferimento per alcune parti.

Answer 6

A rischio di essere ovvio, direi di evitare del tutto la ramificazione. La quantità di spese generali che ciò provoca non deve essere sottovalutata. Anche quando pensi di non poter più resistere (rilasciare uno dei sistemi in produzione, rilasciare due in fase di realizzazione ma anche modificare le richieste per rilasciarne uno) provi ancora a trovare un altro modo: non c'è davvero modo di isolare la funzionalità senza ramificare (ad es. dividere un progetto "comune" e alcuni sottoprogetti)? Non c'è davvero modo di integrare tutto il codice in testa (ad es. Creare classi di strategia che incorporano le differenze o creare interruttori per attivare o disattivare nuove funzionalità)?

Se devi assolutamente ramificarti, sceglierei l'opzione 1. Cerca di unire il minor numero possibile di modifiche e farlo frequentemente.

Answer 7

Impegni in anticipo, impegno frequente.

O in questo caso ... Unisci in anticipo, unisci spesso.

Answer 8

L'integrazione continua è la chiave ... 1 piccola serie di modifiche alla volta ...