Approccio al lavoro con molti programmatori su un modulo / funzione

Un approccio sarebbe quello di suddividere la funzionalità all'interno del modulo in più di una funzione e fare in modo che i programmatori si concentrino su funzionalità o insiemi di elementi il più possibile isolati l'uno dall'altro. Questo può aiutare ad avere troppe situazioni in cui si pestano l'un l'altro. Se ci sono alcune parti della funzionalità comune che superano molti limiti o sono utilizzate da tutte le altre funzionalità, probabilmente vorrai fare quel pezzo prima e qualsiasi funzionalità dipendente può provare a usare il codice del segnaposto locale per aggirare la funzionalità comune incompleta, finché non è completa .

Avere anche il controllo del codice sorgente. Dare a ogni programmatore un ramo separato potrebbe essere un buon modo per farlo, sebbene lo abbia fatto anche su progetti in cui i rami esistevano solo a livello di progetto, quindi dovevamo lavorare tutti sullo stesso ramo e unirci abbastanza regolarmente (di solito una volta per giorno, a volte di più)

Nella programmazione orientata agli oggetti, ci sono un certo numero di best practice che ruotano attorno a alta coesione e il principio di responsabilità singola . L'idea di base è che ogni oggetto dovrebbe fare solo una cosa e una sola.

Se segui questa regola, si incontrano molti meno conflitti. Diverse implementazioni di un metodo? Diversi oggetti strategia contenenti le varie implementazioni. Ogni sviluppatore può lavorare su una strategia diversa, senza conflitti. (Vedi il Pattern di strategia per maggiori informazioni su questo).

Anche se non stai facendo OOP, il principio è ancora valido. Non mettere tutto il codice in un file, ma solo il codice necessario per fare una cosa. Chiama quel codice da una procedura principale, che uno o due sviluppatori possono possedere e gestire.

Comunque lo fai, devi mantenere una buona comunicazione tra i membri del team. Inoltre, sviluppa un buon processo di test di regressione (automatizzato, preferibilmente), in modo da sapere quando un cambiamento sta per rompere qualcosa.

Fai una cosa e fallo bene, quindi documentala e assicurati che i tuoi pari lo capiscano abbastanza bene da usarla. Avere due persone che lavorano su un pezzo di codice molto localizzato è solo uno spreco di tempo per lo sviluppatore e a meno che l'intero modulo consista di due funzioni, nel qual caso probabilmente lo stai facendo comunque, puoi sempre dividerlo in pezzi che possono essere lavorato da singoli programmatori senza interferenze. È una formula semplice che funziona e di solito le deviazioni da questo semplice flusso di lavoro sono un segno di una squadra disfunzionale. Quest'ultima parte è solo la mia opinione su cose come le ho osservate sul posto di lavoro.

• Proviamo a suddividere il lavoro in diverse parti del codice. Ad esempio, un ragazzo può fare i servizi web, un altro la GUI.
• Se due persone cambiano le stesse funzioni, con un moderno sistema di controllo del codice sorgente come TFS non è un grosso problema. Dà solo un conflitto di fusione, chiamate l'altro programmatore alla vostra scrivania e lo risolvete insieme.
• Se hai costantemente conflitti di fusione in una parte del tuo codice, è un collo di bottiglia che devi risolvere. Ciò significa dividere quelle classi in quelle più piccole.