La proprietà del codice individuale è importante? [chiuso]

Sono nel mezzo di una discussione con alcuni colleghi sul fatto che la proprietà del team dell'intera base di codice sia migliore della proprietà individuale dei componenti di esso.

Sono un grande sostenitore dell'assegnazione a ogni membro del team di una quota approssimativamente uguale della base di codice. Permette alle persone di essere orgogliose della loro creazione, offre ai vagliatori di bug un ovvio primo posto per assegnare i biglietti in arrivo e aiuta ad alleviare la "sindrome della finestra rotta".

Inoltre, concentra la conoscenza di funzionalità specifiche con uno (o due) membri del team rendendo le correzioni di errori molto più facili.

Soprattutto, mette l'ultima parola sulle decisioni importanti con una persona che ha molti input invece che con un comitato.

Non sto sostenendo di richiedere l'autorizzazione se qualcun altro vuole cambiare il tuo codice; forse avere la revisione del codice sempre al proprietario, certo. Né sto suggerendo di costruire silos di conoscenza: non ci dovrebbe essere nulla di esclusivo in questa proprietà.

Ma quando ho suggerito questo ai miei colleghi, ho avuto un sacco di respingimenti, sicuramente molto più di quanto mi aspettassi.

Quindi chiedo alla community: quali sono le tue opinioni su come lavorare con un team su una base di codice di grandi dimensioni? C'è qualcosa che mi manca nel mantenere vigile la proprietà collettiva?

Credo che la proprietà della squadra sia molto più vantaggiosa a lungo termine.

Devi solo guardare i seguenti 2 scenari per capire perché concentrare la conoscenza in un numero minimo di persone non è l'ideale:

• Il membro del team incontra uno sfortunato incidente
• Il membro del team incontra una migliore opportunità di lavoro

Naturalmente, la persona / le persone che scrivono sezioni particolari ne avranno una maggiore conoscenza, ma non cedono alla tentazione di renderle l'unico silo di conoscenza. I silos ti daranno vittorie a breve termine con dolori a lungo termine.

Solo perché non hai la proprietà individuale di sezioni di codice, dal momento che l'hai scritto, non significa che non avrai ancora gli aspetti di "orgoglio nella tua creazione", ecc. Non credo che avere la proprietà della squadra lo farà diminuisce qualsiasi sentimento personale di proprietà del codice scritto.

Alla fine, il team possiede il codice. Ma per tutti i motivi che hai citato, abbiamo designato singoli autori per parti specifiche del codice. Ogni autore ha la responsabilità primaria per la parte del codice e la responsabilità secondaria per la base di codice nel suo insieme.

Se si verifica un problema con una parte delle superfici della base di codice, provo a tornare alla persona che originariamente ha scritto il codice per una correzione. Naturalmente, nulla impedisce agli altri membri del team di applicare una correzione; tutti i membri del team dovrebbero conoscere il codice di tutti gli altri. Ma cerchiamo sempre di ottenere prima una correzione dall'autore originale. Dopotutto, hanno scritto il codice; sono i più familiari.

Ho lavorato in ambienti di squadra che, poiché le persone non provavano un senso di appartenenza a ciò che scrivevano, non erano obbligate a scrivere un codice eccellente, ma solo un codice medio.

Mentre sono d'accordo da una posizione aziendale sui motivi per diffondere la conoscenza del prodotto; la realtà è che un individuo che concentra i propri sforzi su una determinata area di qualsiasi cosa, col tempo, diventerà molto più esperto in quella data area.

Ignorare questo è ignorare la scienza. Il cervello purtroppo non è in grado di trattenere tutto ciò che incontra. Richiama ciò che è valido e prezioso in un dato momento, anche se lo stoccaggio diminuisce nel tempo.

Tenderei a concordare con te sul fatto che la proprietà di un modulo o compartimento specifico all'interno della base di codice più ampia produrrà generalmente risultati migliori. Qualcuno che se ne andasse senza preavviso ostacolerebbe il successo? Certamente. Ma far finta che tutti i membri del team debbano avere la stessa conoscenza in merito alla base di codice è ingenuo e non fa nulla per migliorare il codice; tenta di proteggere il codice. La protezione del codice è il ruolo dell'azienda per ovvie ragioni. La durata dello sforzo di un'azienda per proteggere il codice può spesso diventare altrettanto dannosa.

Non ti assicuri che tutti i giocatori della tua squadra possano giocare a quarterback, vero? Direi che assicurarsi che ogni membro della squadra abbia una puntata attraverso la base di codice è sulla stessa linea del tentativo di far giocare ogni quarterback della tua squadra a un livello soddisfacente ... non si somma. Hai dei backup? Certo che lo fai ... ma i membri del team dovrebbero avere un'identità all'interno del team. Credere che tutti siano gli stessi è chiedere dolore di un tipo diverso ...

Non so che la proprietà del codice individuale sia una buona idea. Almeno non nel senso che la gente può dire "Questo è il mio codice e farò quello che voglio con esso". Forse è meglio dire che dovresti avere una gestione individuale del codice : il codice dovrebbe essere di proprietà del team, ma c'è una persona in particolare a cui il team delega la responsabilità e l'autorità.

La ragione di questo è che se è responsabilità di tutti, non è responsabilità di nessuno.

Vorrei sposare la proprietà della squadra sull'individuo per i seguenti motivi:

• Coerenza del codice sull'intero progetto
• Promuove la discussione sul codice, che porta sempre a soluzioni migliori e più controllate
• Se un membro del team è malato (o peggio), un'intera sezione di codice non è soggetta a ritardi
• I membri del team possono lavorare su tutte le parti del progetto, che serve a rendere la revisione del codice integrata nel processo di sviluppo

La specializzazione va bene - per una base di codice di grandi dimensioni ciò può a lungo andare a risparmiare un bel po 'di tempo di comunicazione - ma la proprietà no.

Quello che voglio dire è che l'atteggiamento dovrebbe essere che la squadra ha un bug, e nessuno dovrebbe dire che "oh, solo X può toccare quel codice, quindi non è un mio problema". Se fai parte del team, è anche tua responsabilità correggere i bug nell'intera base di codice, se puoi, e farlo correttamente. La persona X potrebbe essere la scelta migliore per farlo, ma ci si dovrebbe aspettare che lo faccia qualcuno se dovesse farlo. Ciò richiede naturalmente che il codice sia scritto in un modo che consenta e invita i membri del team a lavorare con esso. Avere codice gnarly lo proibirà, quindi cerca un codice chiaro e semplice, poiché ciò consente alla maggior parte degli sviluppatori di lavorarci. Potresti voler andare con la peer review per mantenerlo così.

Non sono d'accordo con te: la proprietà della squadra di una base di codice è un'opzione molto migliore della proprietà individuale.

L'ovvio svantaggio della proprietà individuale è che se succede qualcosa a un dipendente (licenziato, va in pensione, si ammala, ecc.), A meno che non scriva un codice veramente pulito, ci vorrà del tempo prima che qualcun altro adotti quella persona codice, soprattutto se devono anche gestire il proprio codice.

Sono anche troppi strumenti che semplificano la proprietà del team. Revisioni del codice, controllo del codice sorgente: questi sono elementi che incoraggiano il coinvolgimento del team nell'intera base di codice. Inoltre, come si assegna una parte particolare di una base di codice a una sola persona? Hai appena detto che solo questa persona può modificare questo file?

Infine, penso che se una parte di una base di codice si rompe, è troppo facile incolpare la persona che ne era responsabile, e ciò causa solo più problemi.

Penso che tu abbia bisogno di entrambi, perché c'è una tensione tra entrambi gli approcci.

Se per qualsiasi pezzo di codice c'è solo una persona che può lavorarci sopra, è davvero un male a lungo termine per l'azienda, specialmente se / se cresce, perché ogni sviluppatore diventa un punto di fallimento. D'altra parte, la proprietà del codice individuale (si spera) consente tempi di consegna più rapidi, perché lo sviluppatore preferisce generalmente quell'approccio (incentivo), perché lo sviluppatore conosce molto bene il codice, ecc ... C'è anche un problema di tempo: dovrebbe essere possibile riallocare gli sviluppatori su progetti specifici in base alle esigenze aziendali, ma se lo fai quotidianamente, è orribile (se non altro perché gli sviluppatori lo odiano, ma anche perché il costo dello switch è troppo pesante e trascorri la maggior parte del tempo a fare Niente).

IMO, un ruolo di un manager è quello di trovare un buon equilibrio tra entrambi. La revisione del codice, gli standard di codifica, la standardizzazione su una serie di strumenti dovrebbe anche aiutare a ridurre il problema del fallimento. Dopotutto, il punto principale del codice gestibile è affrontare questo problema.

Penso che la proprietà del codice collettivo sia incomparabilmente migliore della proprietà del codice individuale.

Non sono così infastidito dall'argomento del camion: in un modello di proprietà individuale, la perdita di un proprietario è costosa in termini di tempo necessario a qualcun altro a subentrare, ma l'evento è abbastanza raro che il costo ammortizzato è basso.

Piuttosto, penso che la proprietà del codice collettivo porti direttamente a un codice di alta qualità. Questo per due ragioni molto semplici. Innanzitutto, perché la dolorosa verità è che alcuni dei tuoi programmatori non sono buoni come gli altri, e se possiedono un codice, quel codice sarà scarso; dare ai tuoi migliori programmatori l'accesso ad esso migliorerà. In secondo luogo, revisione del codice: se tutti possiedono il codice, tutti possono rivederlo e migliorarlo; anche i bravi programmatori scrivono sottocodici se lasciati ai propri dispositivi.

Lo dico sulla base dell'esperienza nel mio attuale progetto. Miriamo a praticare la proprietà collettiva, ma ci sono alcuni bit del sistema che sono diventati specializzati - io e un altro ragazzo siamo di fatto proprietari del sistema di compilazione, ad esempio, c'è un ragazzo che sta facendo la maggior parte del lavoro sui feed di dati in arrivo , un altro ragazzo che lavora sull'importazione di immagini e così via. In molte di queste aree (in particolare, devo confessare, nella mia zona!), La qualità del codice ha sofferto seriamente - ci sono errori, idee sbagliate, kludges e hack che semplicemente non sopravviverebbero all'attenzione delle altre persone nella squadra.

Noto che potresti ottenere alcuni dei vantaggi della proprietà del codice collettivo avendo la proprietà del codice individuale in cui la proprietà di un particolare bit di codice si sposta regolarmente tra diversi programmatori (diciamo, ogni tre mesi o ogni versione - forse anche ogni iterazione?) . Un equivalente di programmazione della rotazione delle colture. Potrebbe essere divertente. Non ci proverò da solo, comunque.

Non credo che la proprietà del codice del team sia importante quanto avere più collaboratori a comprendere l'architettura di base dei sottosistemi prevalenti.

Ad esempio, abbiamo un paio di ragazzi nel nostro team che creano pagine Web amministrative per i nostri prodotti server. Abbiamo creato un motore di script sul lato server personalizzato in modo da poter chiamare sul server funzioni C direttamente dai nostri script java o html. Penso che sia più importante che i nostri ragazzi "web" capiscano come usare questo motore invece di essere comproprietario delle applicazioni di ogni altra pagina web.

Penso che prendi la proprietà individuale del codice nel momento in cui lo scrivi e poi lo consegni al team. In questo modo ognuno si assume la responsabilità e contribuisce. Tutti dovrebbero voler correggere un errore di codifica che hanno creato. Insieme a una revisione del codice, questo crea standard più elevati. Nessuno vuole il lavoro di ripulire dopo gli altri.

Pensa più responsabilità e meno proprietà. Dopotutto, chiunque stia scrivendo gli assegni è comunque il vero proprietario.

Jim, sono con te al 100%. Sono nel bel mezzo della stessa battaglia nel mio posto di lavoro - motivo per cui mi sono imbattuto nella tua domanda.

Il modo in cui lo vedo è: "quando tutti lo possiedono, nessuno lo possiede".

Per me, non esiste un singolo fattore più importante per la qualità del codice di proprietà e responsabilità.

L'esempio della vita reale lo illustra bene. quale ti occuperesti di più: il tuo prato privato o il parco della comunità? Abbastanza ovvio.

A proposito, ciò non deve necessariamente essere scambiato per "flessibilità della squadra". Significa semplicemente che quando una persona possiede qualcosa la PROPRIA - e se non altro per il giorno.

Per me dipende dalle dinamiche della tua squadra.

Ad esempio, se si dispone di un team che non è unificato per standard, peer review, test metodici o se si dispone di un team in cui i livelli di competenza variano notevolmente tra i membri, potrebbe essere utile cercare una nozione più forte di proprietà del codice con una mentalità modulare più black-box.

In mancanza di questo, ad esempio, l'interfaccia progettata con cura e conforme ai principi SOLID potrebbe essere rapidamente rovinata da qualcuno che non conosce nemmeno i mezzi "SOLID" e desidera aggiungere continuamente nuove funzioni eclettiche all'interfaccia per "praticità", ad es. Questo è di gran lunga il peggiore.

Potresti anche avere a che fare con colleghi sciatti la cui idea di correggere un bug risolve il sintomo senza comprendere il problema alla radice (ad esempio: provare a rispondere a un rapporto di crash semplicemente inserendo soluzioni alternative nel codice solo per nascondere il bug e trasferire il micidiale effetti collaterali a qualcun altro). In tal caso, non è così male come il sabotaggio della progettazione dell'interfaccia e puoi proteggere le tue intenzioni con test unitari accuratamente costruiti.

La soluzione ideale è quella di rafforzare la tua squadra fino a un punto in cui questa nozione di paternità e proprietà non diventa più così importante. La revisione tra pari non riguarda solo il miglioramento della qualità del codice, ma anche il miglioramento del lavoro di squadra. Gli standard non riguardano solo la coerenza, ma migliorano il lavoro di squadra.

Tuttavia ci sono scenari in cui la revisione tra pari e in realtà avere tutti conformi a uno standard è semplicemente senza speranza e porterà un sacco di critici irrimediabilmente inesperti nel mix. Direi che il fatto che la proprietà del codice o la proprietà del team abbia una priorità più forte si baserà sulla capacità del tuo team di eseguire effettivamente un'efficace revisione tra pari e lasciare effettivamente tutti quelli che ne traggono beneficio (entrambi in termini di revisione stessa e di conseguenza si avvicinano maggiormente alla mentalità e agli standard). In squadre grandi, libere e / o disparate, questo potrebbe sembrare senza speranza. Se la tua squadra può funzionare come una "squadra" in cui riesci a malapena a dire chi ha scritto cosa, allora la proprietà esclusiva inizierà a sembrare un'idea sciocca.

In questi tipi di scenari tutt'altro che ideali, questa nozione di proprietà del codice può effettivamente aiutare. Sta cercando di rimediare allo scenario peggiore, ma può aiutare se il lavoro di squadra è generalmente senza speranza di mettere un recinto attorno al codice di un autore. In tal caso, sta diminuendo il lavoro di squadra, ma ciò può essere migliore se il "lavoro di squadra" porta solo a un passo avanti.