Best practice per rinominare, refactoring e rompere le modifiche con le squadre

Quali sono alcune best practice per il refactoring e la ridenominazione negli ambienti del team? Ne ho parlato con alcuni scenari in mente:

1. Se una libreria a cui viene comunemente fatto riferimento viene refactored per introdurre una modifica sostanziale a qualsiasi libreria o progetto che fa riferimento a essa. Ad esempio, cambiare arbitrariamente il nome di un metodo.

2. Se i progetti vengono rinominati e le soluzioni devono essere ricostruite con riferimenti aggiornati ad esse.

3. Se la struttura del progetto viene modificata per essere "più organizzata" introducendo cartelle e spostando progetti o soluzioni esistenti in nuove posizioni.

Alcuni pensieri / domande aggiuntivi:

1. Cambiamenti come questo o il dolore che ne risulta sono indicativi di una struttura andata male?

2. Chi dovrebbe assumersi la responsabilità di correggere gli errori relativi a un cambiamento radicale? Se uno sviluppatore apporta una modifica sostanziale, dovrebbe essere responsabile di accedere ai progetti interessati e aggiornarli o dovrebbe avvisare gli altri sviluppatori e chiedere loro di cambiare le cose?

3. È qualcosa che può essere fatto su base programmata o è qualcosa che dovrebbe essere fatto il più frequentemente possibile? Se un refactoring viene rimandato troppo a lungo, è sempre più difficile riconciliarsi, ma allo stesso tempo in un giorno impiegando incrementi di 1 ora per correggere un build a causa dei cambiamenti che avvengono altrove.

4. È una questione di un processo di comunicazione formale o può essere organico?

Ciascuno degli scenari che hai elencato rientra nella categoria di "API / codice pubblicato". Questo è difficile da riformattare, quindi non si dovrebbe cambiare nulla alla leggera. Piuttosto, dovrebbe negoziare preventivamente le modifiche pianificate con tutte le parti coinvolte. È almeno una questione politica quanto tecnica.

Quindi il consiglio numero uno al riguardo di Martin Fowler è di non pubblicare prematuramente le interfacce (nomi e strutture del progetto) .

Tuttavia, se è già stato fatto e deve essere riparato, probabilmente è meglio provare a fare le modifiche necessarie nel minor numero di passaggi possibile, per ridurre al minimo l'interruzione di altre parti. Che si discosta abbastanza dal concetto originale di refactoring, ma per una buona ragione.

Inoltre, se possibile, prendere in considerazione l' aggiunta del nuovo metodo (deprecando quello esistente) invece di rinominare quello esistente. Ciò garantisce che il codice client non si interrompa e fornisce loro un periodo di transizione per aggiornare il proprio codice per conformarsi all'API più recente. Lo svantaggio è che complica la tua API. Sebbene lo stato sia solo temporaneo, tuttavia potrebbe essere necessario molto tempo prima che sia possibile rimuovere in sicurezza metodi API obsoleti (nel caso della libreria di classi Java, anni).

È quasi sempre possibile evitare questi problemi eseguendo il refactoring in due passaggi. Nel primo passaggio, introdurre il nuovo codice e deprecare il vecchio codice. Quando tutti i team sono passati al nuovo codice, elimina il vecchio codice. Uso anche questa tecnica per refactoring incrementale di un singolo modulo. In questo modo posso limitare la quantità di codice che deve essere modificata tra le esecuzioni di test.

Si noti che questo è uno dei motivi principali per disporre di un server di build, che esegue test.

Se succede qualcosa che interromperà un determinato programma, ti viene detto il più rapidamente possibile e puoi dare la caccia al colpevole e risolvere i problemi mentre i dettagli sono ancora aggiornati.