Come gestite il refactoring con una base di codice di grandi dimensioni e molti sviluppatori?

Vorrei prevenire una situazione in cui due sviluppatori refactoring lo stesso codice contemporaneamente senza prima parlarne, probabilmente usando uno strumento di qualche tipo, forse un plug-in Eclipse. Puoi aiutare?

Abbiamo 4,5 milioni di righe di codice e oltre 20 team di sviluppatori in quattro continenti.

Idealmente, vorrei che il secondo degli sviluppatori menzionato in precedenza notasse che qualcun altro sta lavorando sullo stesso codice e parla con il primo prima di modificare qualsiasi cosa.

Conosci una soluzione?

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

Suggerirei sicuramente una sorta di approccio gerarchico per allocare il lavoro di refactoring. Gli sviluppatori potrebbero essere raggruppati logicamente in sotto-team, ciascuno responsabile di aree specifiche del codice. A seconda di come preferisci strutturare i team, ognuno potrebbe avere un ruolo "guida", 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 sembri troppo formale e arretrato per alcuni, ma penso sia preferibile che oltre 20 sviluppatori utilizzino un approccio "gratuito per tutti" per il refactoring di un sistema di grandi dimensioni. Alcuni refactoring avranno luogo ad alto livello (ad es. Come comunicherà il modulo X con il modulo Y), nel qual caso avrai bisogno di persone in grado di effettuare chiamate al livello appropriato. Non tutti gli sviluppatori del team dovrebbero prendere decisioni sull'architettura, quindi una gerarchia è quasi imposta in ogni caso, anche se si sceglie di ignorarlo.

Quindi, fondamentalmente, ci sono strumenti per soddisfare i requisiti di base proposti, ma nessuno strumento sostituirà le comunicazioni appropriate e avrà un piccolo numero di persone alla guida dell'architettura generale del 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 del refactoring. Assegna ogni problema a un solo sviluppatore
3. Alcuni sistemi di controllo della versione 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 funzionalità, ma se gli sviluppatori si calpestano costantemente, questo è qualcosa che potresti voler considerare.
4. Esegui 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 sarebbe d'aiuto se il refactoring è contenuto nei moduli. Tuttavia, se qualcuno esegue un refactoring su un problema trasversale come la registrazione o la sicurezza, ciò influirà su molti file per definizione. Questi devono essere gestiti con cura soprattutto se non hai già approfittato degli approcci aop.

Esistono / erano sistemi di controllo della versione che rendono gli sviluppatori il codice di checkout prima che possano essere modificati, ma presentano problemi propri. La migliore pratica è convincere gli sviluppatori a impegnarsi e aggiornarsi spesso. Uno sviluppatore può quindi contrassegnare una classe come deprezzata e impegnarsi quindi se l'altro sviluppatore si aggiorna prima di iniziare il suo refactor vedrà l'intento.

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

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 includerlo anche tu, avrai bisogno di alcune cose avanzate (una sorta di meccanismo di innesco / qualche cosa personalizzata forse).

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

4,5 milioni di LOC sono un enorme sandbox in cui giocare, quindi in una soluzione ben progettata e progettata dovresti raramente imbatterti in una situazione in cui più team di sviluppatori si calpestano l'un l'altro. Il fatto che ciò accada più che per coincidenza sta parlando di alcuni potenziali difetti di progettazione che dovrebbero essere esaminati.

Poche cose:

1. Separare i moduli su cui lavorare
2. Parlando di cambiamenti prima che vengano fatti [con tutti gli sviluppatori]
3. Test unitari [per verifica ed evitamento per la rottura di cose correlate]
4. Come gli altri hanno menzionato un VCS