Spero di poterti aiutare un po ', o almeno indicarti la giusta direzione!
Un po 'come una dichiarazione di non responsabilità, tuttavia, è un argomento enorme - e penso che ci voglia davvero " farsi buttare dentro " per capire a fondo. Detto questo, darò una breve panoramica dei due problemi principali:
- Il codice e il controllo del codice sorgente
- Comunicazioni e alcuni consigli.
Riguardo specificamente ai progetti OOP - Onestamente non riesco a vedere troppi problemi specifici di OOP che non sono presenti altrove.
In effetti, penso che la programmazione in stile OOP sia incredibilmente adatta allo sviluppo del team. Un'etica chiave di OOP è che non dovrei conoscere tutti i dettagli di ogni oggetto con cui interagisco: ho solo bisogno di sapere cosa può fare e come posso farlo.
Le astrazioni che OOP può fornire sono fantastiche in una squadra.
Controllo della fonte
Deve esserci un posto centrale per la memorizzazione del progetto e uno che consenta a più sviluppatori di accedere alla base di codice in qualsiasi momento. È qui che entrano in gioco sistemi come Git (o SVN).
Posso solo parlare in modo specifico di Git, dato che non ho mai usato SVN - comunque ho capito che sono simili ma con una terminologia diversa.
Usando Git posso creare un repository con tutto il codice sorgente per un determinato progetto e quindi consentire al mio team di accedere al repository. Per ogni funzione o correzione di bug che viene effettuata, i singoli sviluppatori possono creare il proprio "ramo", il che significa che lo sviluppo può avvenire su tracce parallele.
Una volta completata, una funzionalità o correzione può essere " unita " nuovamente alla base di codice del progetto principale. Eventuali " conflitti " possono quindi essere rilevati da Git e risolti a livello di sorgente dallo sviluppatore responsabile.
Non sono sicuro che avresti usato Git prima, ma all'inizio può sembrare piuttosto complesso - ma grazie alla sua recente popolarità (in parte a Github ) ci sono un sacco di tutorial e risorse là fuori.
Se non l'hai mai usato prima, ti consiglio di iscriverti a GitHub e di provare in questo modo! (In alternativa, Bitbucket è un'alternativa simile, ma ti consente di avere repository privati gratuitamente.)
Git Flow è un eccellente flusso di lavoro basato su Git che è incredibilmente utile per i team. Come Git in generale, una volta che ci lavori per un po 'diventa difficile immaginare di lavorare in una squadra senza di essa!
comunicazioni
Una volta superate tutte le barriere tecniche, si arriva davvero alla questione fondamentale che affligge la maggior parte dei progetti (tecnici o meno) - e questa è la comunicazione.
L'intero team deve essere consapevole di chi sta facendo cosa, quando lo sta facendo e di cosa influenza.
La responsabilità deve essere definita chiaramente
Ciò è ovvio, ma la maggior parte dei progetti utilizzerà una qualche forma di sistema di ticketing - in cui vengono registrate eventuali richieste di funzionalità o bug e successivamente assegnate a un membro specifico dello staff. ( JIRA , Unfuddle ecc.) Spesso questi sono integrati nel sistema di controllo della sorgente che rende la vita un po 'più semplice. (BitBucket e GitHub forniscono entrambi il rilevamento dei problemi per i repository Git ospitati con loro.)
Ciò arresta o aiuta almeno a prevenire che gli sviluppatori lavorino accidentalmente sugli stessi problemi.
Questa non è una soluzione completa però; devi comunque assicurarti che gli sviluppatori siano consapevoli delle responsabilità degli altri sviluppatori. So che in passato ho risolto altri problemi che mi sono imbattuto durante la correzione di un bug specifico, semplicemente perché ha senso. (" Beh, sono già qui. Questo potrebbe fare con un refactor e forse posso verificare eventuali altri problemi. ") Quindi ho dovuto scusarmi con altri sviluppatori mentre stavano lavorando su quegli altri problemi che ho risolto - sprecando entrambi i nostri tempi.
In generale, questi problemi possono essere risolti da ...
Incontri regolari
Alcune metodologie di gestione / sviluppo del progetto impongono specifici metodi di comunicazione o intervalli di incontro. In generale, i sistemi più produttivi che ho visto sono stati incontri stand-up mattutini in cui tutti i membri di un team ridurranno rapidamente ciò che stanno facendo, se si limita questo solo ai membri del team di sviluppo e si hanno linee guida chiare su ciò che comunicare quindi questi possono essere incredibilmente efficaci. Ho sempre cercato di attenermi a:
Sto lavorando su X,
Per ottenere / correggere Y,
Ciò comporta la modifica / modifica di Z.
Gli altri membri del team possono immediatamente capire che " Fergus sta lavorando per correggere quel bug che è stato registrato l'altro giorno, tuttavia ciò significa che sta lavorando su un codice che devo esaminare - Verificherò con lui prima di apportare eventuali modifiche. ".
Incontri di architettura
Di recente ho lavorato con un grande team che ha avuto una " chiacchierata tecnica " quindicinale , in cui si discutevano questioni più grandi / architettoniche. Ogni membro del team ha avuto il tempo di comprendere i problemi più grandi che il progetto deve affrontare e di discutere potenziali soluzioni.
Personalmente mi è piaciuto molto, non ho contribuito molto perché ero abbastanza nuovo nel progetto, ma essere in grado di ascoltare le discussioni mi ha dato molte idee; abbastanza presto ho potuto capire il progetto e gli stili di pensiero individuali.
La comunicazione è l'unico problema che può far crollare qualsiasi squadra. Tecnico o no, se le persone non sono consapevoli del quadro più ampio, allora c'è una maggiore possibilità che falliscano.
Altri problemi
È bene assicurarsi che tutti abbiano la stessa configurazione o lo stesso stile quando si lavora in gruppo. Cosa voglio dire?
Configurazione
Se stai lavorando a un progetto Java - forse assicurarti (almeno per gli ambienti di sviluppo, sicuramente non per i test). Le versioni JVM sono comuni tra il team potrebbe essere una buona idea? Quindi IDE. Aiuta soprattutto se l'intero team utilizza Eclipse o NetBeans o il tuo IDE preferito.
In un progetto Web potrebbe essere che tutti gli sviluppatori abbiano bisogno di uno stack specifico; con specifiche versioni di Apache o PHP .
Pensare a fattori come questo permette alla squadra di "gelificare" un po 'più velocemente nella mia mente.
Stile
Schede vs spazi? CamelCase o spacing_with_underscores? Per quanto piccole possano essere queste domande quando lavori da solo, quando lavori con un team più grande vuoi davvero lottare per uno stile comune.
In effetti, non dovresti davvero essere in grado di dire chi ha scritto una specifica sezione di codice - dovresti semplicemente sapere che appartiene .
Questo è il motivo per cui molti progetti open source pubblicano apertamente linee guida / styleguides in formato codice sorgente - per avere un'idea di cosa contengano, dai un'occhiata a Google StyleGuides per i loro progetti open source.
Compiti e test unitari
Questo non si limita ai team, ma ho intenzione di toccarlo rapidamente per una ragione in particolare: rende la vita di squadra molto più semplice.
Se hai un flusso di lavoro complesso con molte dipendenze o un lungo processo di compilazione, spesso è utile automatizzarlo utilizzando un task runner. Per i progetti Web GruntJS è fantastico, anche se provengo da Java, penso che Apache Ant possa essere abbastanza simile.
Come individuo utilizzo GruntJS per costruire il mio sito prima di distribuirlo sul mio server FTP: un solo comando Grunt è tutto ciò di cui ho bisogno per compilare e minimizzare il mio CSS / Sass , comprimere le mie risorse e quindi caricare i miei file.
Tuttavia, come membro del team, posso usare GruntJS per verificare di non aver superato alcun test e di non aver introdotto alcun bug non essendo pienamente consapevole di altre parti del progetto. Questo è ovviamente, in aggiunta ai benefici che mi offre come singolo sviluppatore.
Posso anche usarlo in modo da poter clonare un progetto usando il mio pacchetto di controllo del codice sorgente (Git) - ed eseguire un comando per installare tutte le mie dipendenze. Questo è un grande vantaggio, poiché il tempo impiegato per ottenere un nuovo sviluppatore nella posizione in cui può effettivamente iniziare a sviluppare può essere piuttosto grande - senza nemmeno considerare il tempo necessario per abituarsi a una base di codice non familiare.
Documentazione
I migliori progetti che ho visto hanno avuto documentazione (e spesso abbastanza eccessiva) rivolta agli sviluppatori. Questo tipo di documenti può spiegare cose come:
1. L'ambiente di sviluppo:
"Attualmente stiamo distribuendo su un server che esegue uno stack LAMP , poiché tali sviluppatori dovrebbero scegliere come target le versioni descritte in ..."
2. Flusso di lavoro
"Tutte le funzionalità devono essere sviluppate su un ramo" feature / * "e unite al ramo" testing "prima di essere considerate pronte per il rilascio."
3. Responsabilità nel team:
"Per problemi con il database, parla con Steve. Per problemi con la piattaforma, parla con David."
4. Una " pipeline " per il futuro
"Quando si sviluppa un nuovo codice, ricordare che a partire da giugno 2014 desideriamo implementare il codice x - legacy potrebbe essere necessario rivedere prima che ciò accada."
Esempi
Potrebbe valere la pena esaminare il flusso di lavoro di un progetto open source per avere un'idea di come funziona, sia esso consolidato con il proprio flusso di lavoro (spesso ampiamente documentato) o uno dei tanti esempi su GitHub.
Un'ultima parola di avvertimento
Se ti ritrovi a lavorare in una squadra che riesce a fare tutto bene ... odierai di essere altrove ..! Prendilo da me, una volta che hai sperimentato una buona squadra, improvvisamente problemi altrove possono davvero trascinarti giù. (Questa è una storia per un altro post comunque!)