Questa è una domanda piuttosto generica, ma di cui mi sono interrogato da un po ': esiste un modo standardizzato, generalmente accettato o anche solo sistematico per scrivere codice come gruppo?
Ad esempio, in un progetto scritto in C ++, uno sviluppatore scrive una classe, che passa al successivo sviluppatore con una rapida spiegazione di cosa fa ogni metodo?
Non ho mai visto un modo standardizzato e formalizzato per farlo, ma ho visto due modelli comuni.
Proprietà delle caratteristiche - ogni sviluppatore si assume la responsabilità esclusiva di una particolare funzionalità del sistema e implementa questo attraverso tutti i livelli appropriati.
Vantaggio chiave: uno sviluppatore, con una piena comprensione dell'intera funzionalità, può lavorare su tutti i livelli in modo coerente.
Svantaggio chiave: poiché molti sviluppatori diversi finiscono per lavorare su ciascun componente, può finire con una netta mancanza di coerenza a meno che non siano in atto buone convenzioni.
Proprietà dei componenti - ogni sviluppatore si assume la responsabilità esclusiva di uno specifico componente / livello (interfaccia utente, servizi, accesso ai dati, schema dei dati, ecc.). Le funzionalità sono implementate dalla collaborazione tra gli sviluppatori.
Vantaggio chiave: ogni componente è scritto da un singolo sviluppatore, assicurando che abbia uno stile coerente e "unità di visione".
Svantaggio chiave: ci sono sempre alcuni componenti che richiedono uno sviluppo maggiore rispetto ad altri, il che comporta un carico sbilanciato su alcuni sviluppatori.
Però, questi sono esclusivi - anche se un particolare gruppo si iscrive principalmente a uno, alcune cose tendono ad essere fatte nell'altro modo.
In base alla mia esperienza, la proprietà delle funzionalità ha avuto più successo a lungo termine rispetto alla proprietà dei componenti, principalmente perché la conoscenza del sistema è più diffusa, aiutando a indirizzare il rischio delle persone chiave . Ma questa è solo la mia esperienza.
in Agile, la risposta è tuttavia il team vuole che funzioni
potrebbero essere caratteristiche, potrebbero essere storie, potrebbero essere test, potrebbero essere compiti, potrebbero essere accoppiati, potrebbero essere ... qualsiasi cosa.
alcuni negozi di sviluppo trasferiscono la proprietà del codice al cambio di turno e utilizzano tre turni in fusi orari a 8 ore di distanza per lo sviluppo continuo
alcuni negozi di sviluppo assegnano interi sottosistemi a una persona
ci sono molti modi ...
Sto facendo una risposta a parte perché, sebbene al suo interno ci sia una parte della risposta di Bevan mi sto espandendo un po '. Anch'io non ho mai visto un modo formale per farlo.
Mine è un negozio Agile che costruisce un'app SaaS, con un team di 4 sviluppatori e un tester, che lavora su sprint di 2 settimane. Quando il team decompone le storie, creiamo un ticket principale e biglietti per bambini che approssimativamente risolvono i cambiamenti del modello, le modifiche alle modifiche e il controller (in senso lato) per raggiungere gli obiettivi di quella storia.
Quando arriva il momento di lavorare, uno sviluppatore afferra il biglietto genitore, e per la vita di quel lavoro all'interno dello sprint, diventa il "proprietario" del codice che va a realizzare quella storia. Tuttavia, è abbastanza comune che altre persone del team lavorino alle storie dei bambini a seconda dei punti di forza personali (ad es. UI, database, una dose extra di conoscenza della logica aziendale). Il "proprietario" del biglietto genitore è il go-to per domande su quella caratteristica o componente (a seconda dei casi) fino a quando tutti i bambini sono completati e il proprietario lavora attraverso l'intero articolo a livello genitore ed è pronto per l'invio come un pacchetto per lo stato di revisione del codice.
Quando gli oggetti passano attraverso la revisione del codice, lo fanno anche a livello di singolo bambino, e l'unica regola è che nessuno rivede il proprio codice (ovviamente). Quindi, mentre lo sviluppatore A potrebbe essere il proprietario del biglietto genitore, avrebbe potuto lavorare su Pezzo 1, 2, 3 mentre lo sviluppatore B lavorava su Pezzo 4, 5 e Sviluppatore C sul pezzo 6, 7. Lo sviluppatore A sarebbe in grado di revisione del codice 4, 5, 6, 7, lo sviluppatore B poteva eseguire la revisione del codice 1, 2, 3, 6, 7, lo sviluppatore C poteva eseguire la revisione del codice 1, 2, 3, 4, 5. Quando il codice passa attraverso la revisione del codice, va alla prova.
Il tester testa ogni bambino in modo indipendente se ha i suoi criteri di accettazione e il genitore nel suo insieme (che ha sicuramente i suoi criteri di accettazione). Ecco dove entra in gioco la "proprietà": il proprietario del genitore è responsabile di eventuali correzioni nel genitore o nei suoi figli . "Responsabile" in questo caso può significare "avere una conversazione con chiunque abbia lavorato a un bambino problematico", ma è il proprietario del genitore che ha ragione.
Il pensiero con tutto questo, e ha funzionato in modo ridicolo e scioccante con la mia squadra, è che ognuno è sempre sia proprietario che aiutante, ognuno pratica costantemente la collaborazione e la comunicazione, e ognuno di noi è abbastanza familiare con ogni pezzo di il sistema che dopo il rilascio chiunque può essere il proprietario di qualsiasi cosa per il breve periodo di tempo in cui i proprietari hanno un ruolo (ad esempio all'interno di uno sprint).
La risposta breve - No, non ci sono modi standard di fare nulla, ma una cosa che quasi tutti i progetti iniziano insieme è che quasi tutto sarà "sconosciuto" all'inizio.
Con specifico riferimento alla tua domanda sulla delega della responsabilità per le singole classi (o altri dettagli di implementazione per quella materia) - questi tipi di decisioni non possono sempre essere inventati perché gli sviluppatori spesso non hanno abbastanza informazioni al tempo il lavoro è diviso. È abbastanza comune non avere idea di quali classi verranno create fino a quando lo sviluppo non avrà avuto inizio e non esiste un qualche tipo di base di lavoro / prototipo.
Più tipicamente, gli sviluppatori potrebbero semplicemente concordare i dettagli della periferia per qualsiasi parte del sistema di cui sono responsabili, in modo che altri sviluppatori abbiano un'idea di come i bit si integreranno insieme, senza preoccuparsi di come funzionerà effettivamente.
In pratica, di solito significa definire i limiti di comunicazione (interni o esterni) che verranno utilizzati per connettere le caratteristiche / componenti / moduli - ad es. tipi di interfaccia, strutture dei messaggi, formati dei dati, flussi di input / output, tipi di dati condivisi, ecc. La scissione finale della responsabilità può o meno significare che più sviluppatori lavorano sulle stesse classi / funzioni; potrebbe anche significare che le classi presenti nel progetto originale vengono scartate e l'architettura generale viene successivamente modificata (ma si spera che le interfacce di base e i meccanismi di comunicazione siano ancora ampiamente utilizzabili)
Leggi altre domande sui tag teamwork development-process