Best practice per la ridenominazione, il refactoring e la violazione delle modifiche con i team

Naviga le tue risposte
10

Quali sono le migliori pratiche per il refactoring e la rinomina negli ambienti di squadra? Lo presento con alcuni scenari in mente:

  1. Se una libreria a cui si fa comunemente riferimento viene refactored per introdurre una modifica di rottura a qualsiasi libreria o progetto che la fa riferimento. Per 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.

Alcune domande / domande aggiuntive:

  1. Le modifiche di questo tipo o il dolore provocato indicano un'indicazione di struttura andata a male?

  2. Chi dovrebbe assumersi la responsabilità di correggere gli errori relativi a un cambiamento di rottura? Se uno sviluppatore apporta una modifica alla rottura dovrebbe essere responsabile di andare nei progetti interessati e aggiornarli o dovrebbe avvisare altri sviluppatori e spingerli a cambiare le cose?

  3. È qualcosa che può essere fatto su base pianificata o è qualcosa che dovrebbe essere fatto il più frequentemente possibile? Se un refactoring viene rimandato troppo a lungo, è sempre più difficile conciliare, ma allo stesso tempo in un giorno spendendo incrementi di 1 ora per fissare una build a causa di cambiamenti avvenuti altrove.

  4. Si tratta di un processo di comunicazione formale o può essere organico?

posta David in Dakota 25.02.2011 - 17:52
fonte

3 risposte

12

Ciascuno degli scenari che hai elencato rientra nella categoria di "API / codice pubblicato". Questo è difficile da refactoring, quindi non si dovrebbe cambiare nulla alla leggera. Piuttosto, (s) dovrebbe negoziare in anticipo le modifiche pianificate con tutte le parti coinvolte. È almeno tanto un problema politico quanto tecnico.

Quindi il consiglio numero uno in merito a questo da Martin Fowler è non pubblicare le tue interfacce (nomi e strutture del progetto) prematuramente .

Tuttavia, se è già stato fatto e deve essere corretto, probabilmente è meglio provare a fare i cambiamenti necessari nel minor numero possibile di passaggi, per ridurre al minimo l'interruzione delle altre parti. Che devia abbastanza lontano dal concetto originale di refactoring, ma per una buona ragione.

Inoltre, se possibile, considera aggiungendo il nuovo metodo (mentre 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 loro codice in modo che sia conforme all'ultima API. Lo svantaggio è che complica la tua API. Sebbene lo stato sia solo temporaneo, tuttavia potrebbe essere necessario molto tempo prima di poter rimuovere in modo sicuro i metodi API deprecati (nel caso della libreria di classi Java, anni).

    
risposta data 25.02.2011 - 17:56
fonte
5

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

    
risposta data 25.02.2011 - 18:02
fonte
4

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

Se succede qualcosa che rompe un dato programma, ti viene detto il più rapidamente possibile e puoi cacciare il colpevole e risolvere i problemi mentre i dettagli sono ancora freschi.

    
risposta data 25.02.2011 - 18:06
fonte

Leggi altre domande sui tag

Chi progetta i database nello sviluppo web? [chiuso] Tecniche avanzate di sovversione, cosa mi manca?