Come gestisci il refactoring con una grande base di codice e molti sviluppatori?

Molti sistemi di controllo del codice sorgente di seconda generazione funzionano utilizzando un "checkout" connesso che informa il server che si intende modificare un file. Gli esempi includono TFS, SourceGear Vault e molti altri. In questo modo, tecnicamente può soddisfare i tuoi requisiti. Come ha rilevato Adam Butler, tuttavia, questi tipi di strumenti hanno i loro problemi (senza entrare in un lungo dibattito - supporto limitato per il lavoro offline e in generale un flusso di lavoro di sviluppo controproducente).

Suggerirei sicuramente una sorta di approccio gerarchico all'assegnazione del lavoro di refactoring. Gli sviluppatori potrebbero essere raggruppati logicamente in sottogruppi, ciascuno responsabile di aree specifiche del codice. A seconda di come ti piace strutturare i team, ognuno di essi potrebbe avere un ruolo di "lead" che è responsabile della progettazione di alto livello dell'area del team. Questa struttura dovrebbe essere ben nota agli sviluppatori e dovrebbe semplificare la comunicazione per il refactoring. Sono sicuro che questo approccio sembra troppo formale e arretrato per alcuni, ma penso che sia molto preferibile avere più di 20 sviluppatori che usano un approccio "gratuito per tutti" per il refactoring di un sistema di grandi dimensioni. Alcuni refactoring si svolgeranno ad alto livello (ad esempio, come il modulo X comunichi con il modulo Y), nel qual caso avrai bisogno di persone che possano effettuare chiamate al livello appropriato. Non tutti gli sviluppatori del team dovrebbero prendere decisioni architettoniche, quindi una gerarchia è quasi sempre imposta, anche se si sceglie di ignorarla.

Quindi, fondamentalmente, ci sono strumenti per soddisfare i requisiti di base che hai richiesto, ma nessuno strumento sostituirà le comunicazioni appropriate e un numero limitato di persone che guidano l'architettura generale del tuo progetto.

1. Assicurarsi che agli sviluppatori vengano assegnati moduli specifici.
2. Avere un sistema di tracciamento di attività / bug che tiene traccia di ogni modifica di refactoring. Assegna ciascun problema a un solo sviluppatore
3. Alcuni sistemi di controllo versioni hanno la possibilità di bloccare un file in modo che solo uno sviluppatore possa disporre dei diritti di aggiornamento sul file. Non ho mai usato questa funzione, ma se gli sviluppatori si passano costantemente l'un l'altro, è qualcosa che potresti voler prendere in considerazione.
4. Avere test unitari in modo che anche se gli sviluppatori lavorano sullo stesso file, sai che le loro modifiche non interrompono l'app in alcun modo.
5. Tutto quanto sopra potrebbe aiutare se il tuo refactoring è contenuto all'interno dei moduli. Tuttavia, se qualcuno esegue un refactoring su un problema trasversale come la registrazione o la sicurezza, influenzerà molti file per definizione. Questi devono essere gestiti con cura soprattutto se non hai già sfruttato gli approcci già esistenti.

Esistono / erano sistemi di controllo delle versioni che rendono il codice di verifica degli sviluppatori prima che possano essere modificati, ma questi hanno una serie di problemi. Una pratica migliore consiste nel far sì che gli sviluppatori si impegnino e si aggiornino spesso. Uno sviluppatore potrebbe quindi contrassegnare una classe come deprecata e commettere, quindi se l'altro sviluppatore si aggiorna prima di avviare il proprio refactatore, vedrà l'intenzione.

La tecnologia non può risolvere i problemi sociali. Devi far dialogare i tuoi sviluppatori e coordinare il loro lavoro. Con 20 squadre, alcune strutture e regole saranno essenziali. Dovrai supportarli con soluzioni tecnologiche, ma le persone vengono prima di tutto.

Se lasci notice that someone else is working on the same piece of code and talk to the first one before modifying anything , come da quello che hai detto, hai bisogno di un sistema di controllo della versione (CVS / SVN / GIT). Non sono sicuro, però, ma se vuoi includere anche questo, avrai bisogno di alcune cose avanzate (una sorta di meccanismo di attivazione / qualcosa di personalizzato forse).

Gli sviluppatori che bloccano i file nel controllo del codice sorgente dovrebbero risolvere facilmente il problema, ma penso che potresti avere problemi più grandi.

4.5 milioni di LOC's sono un enorme sandbox in cui giocare in una soluzione ben progettata e architettata, che raramente si può incontrare in una situazione in cui più team di sviluppatori si pestano l'un l'altro. Il fatto che ciò accada più che per caso sta a indicare alcuni seri potenziali difetti di progettazione che dovrebbero essere esaminati.

Alcune cose:

1. Separa i moduli su cui lavorare
2. Parlare di modifiche prima che vengano apportate [con tutti gli sviluppatori]
3. Test unitario [per verifica ed evitamento per violazione di cose correlate]
4. Come gli altri hanno menzionato un VCS