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

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

Hai solo bisogno di guardare ai seguenti 2 scenari per capire perché concentrare le conoscenze in un numero minimo di persone non è l'ideale:

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

Naturalmente, le persone / persone che scrivono particolari sezioni avranno una maggiore conoscenza di esso, ma non cedere alla tentazione di renderle l'unico silo di conoscenza. Silos ti darà vittorie a breve termine con dolori a lungo termine.

Solo perché non hai la proprietà individuale delle sezioni di codice, dal momento che l'hai scritto, non significa che non avrai ancora gli aspetti di "orgoglio per la tua creazione", ecc. Non credo di avere una squadra la proprietà ridurrà di molto i sentimenti personali di proprietà del codice scritto.

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

Se si verifica un problema con una parte della base del codice, cerco di tornare alla persona che ha originariamente scritto il codice per una correzione. Ovviamente, nulla impedisce agli altri membri del team di applicare una correzione; ci si aspetta che tutti i membri del team conoscano il codice di tutti gli altri. Ma cerchiamo sempre di ottenere prima una correzione dall'autore originale. Dopotutto, hanno scritto il codice; sono quelli che ci sono più familiari.

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

Mentre sono d'accordo da una posizione aziendale sulle ragioni per diffondere la conoscenza del prodotto; la realtà è che un individuo che concentra i propri sforzi su una data area di qualcosa, nel tempo, diventerà molto più esperto nell'area data.

Ignorare questo è ignorare la scienza. Il cervello purtroppo non è in grado di conservare tutto ciò che incontra. Ricorda ciò che è valido e prezioso in un dato momento, eppure anche quello spazio di archiviazione diminuisce nel tempo.

Tenderei ad essere d'accordo con te sul fatto che la proprietà di un modulo o compartimento specifico all'interno della base di codice più ampia generalmente produce risultati migliori. Qualcuno che se ne andasse senza preavviso ostacolerebbe il successo? Certamente. Ma fingere che tutti all'interno del team abbiano la stessa quantità di conoscenza per quanto riguarda la base di codice è ingenuo e non fa nulla per migliorare il codice; tenta di proteggere il codice. Proteggere il codice è il ruolo del business per ovvi motivi. Le lunghezze di sforzo a cui un business andrà a proteggere il codice possono spesso diventare dannose allo stesso modo.

Non ti assicuri che ogni giocatore della tua squadra possa giocare a quarterback, vero? Direi che fare in modo che ogni membro del team abbia un interesse nella base del codice è la stessa cosa che cercare di far giocare ogni giocatore della tua squadra a livello di quarterback a un livello soddisfacente ... non si sommano. Hai dei backup? Certo che lo fai ... ma i membri del team dovrebbero avere un'identità all'interno del team. Credere a tutti è la stessa cosa è chiedere dolore di un tipo diverso ...

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

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

Vorrei sposare la proprietà del team 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 della squadra è malato (o peggio), un'intera sezione di codice non è soggetta a ritardi
• I membri del team possono lavorare su tutte le parti del progetto, il che serve a rendere la revisione del codice integrata nel processo di sviluppo

La specializzazione va bene - per un grande numero di codice questo può a lungo andare risparmiare un po 'di tempo di comunicazione - ma la proprietà non lo è.

Quello che voglio dire è che l'atteggiamento dovrebbe essere che il gruppo 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 responsabilità dell'utente correggere gli errori nell'intera base di codice, se possibile, e farlo correttamente. La persona X potrebbe essere la scelta migliore per farlo, ma tutti dovrebbero farlo se dovessero farlo. Ciò richiede naturalmente che il codice sia scritto in modo che permetta a e di invitare ai membri del team di lavorare con esso. Avere un codice gnarly lo proibirà, quindi cerca un codice semplice e chiaro, in quanto consente alla maggior parte degli sviluppatori di lavorare con esso. Potresti voler andare con la peer review per mantenerlo in questo modo.

Non sono d'accordo con te: la proprietà del team di un codebase è un'opzione molto migliore della proprietà individuale.

L'evidente svantaggio della proprietà individuale è che se succede qualcosa a un dipendente (licenziato, in pensione, ammalato, ecc.), a meno che non abbia scritto veramente codice pulito, ci vorrà un po 'di tempo prima che qualcun altro adotti il codice di quella persona, soprattutto se devono anche gestire il proprio codice.

Sono anche troppi strumenti che facilitano la gestione della squadra. Revisioni del codice, controllo del codice sorgente: sono queste le cose che incoraggiano il coinvolgimento del team nell'intera base di codice. Inoltre, come assegni una parte particolare di una base di codice a una sola persona? Dici solo che questa persona può modificare questo file?

Infine, penso che se una parte di un codebase si rompe, è troppo facile incolpare la persona che ne è responsabile, e questo 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, questo è davvero brutto a lungo termine per l'azienda, specialmente se / se cresce, perché ogni sviluppatore diventa un punto di fallimento. D'altro canto, la proprietà del codice individuale (si spera) consente tempi di consegna più rapidi, perché in genere gli sviluppatori preferiscono tale approccio (incentivo), perché lo sviluppatore conosce molto bene il codice, ecc ... C'è anche un problema di tempo: dovrebbe essere possibile per riallocare gli sviluppatori su progetti specifici a seconda delle esigenze aziendali, ma se lo fai quotidianamente, è orribile (se non altro perché gli sviluppatori lo odiano, ma anche perché il costo degli switch è troppo pesante e passi la maggior parte del tuo tempo a fare niente).

IMO, un ruolo di un manager è trovare un buon equilibrio tra entrambi. La revisione del codice, gli standard di codifica, la standardizzazione di un insieme di strumenti dovrebbero anche contribuire 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 camion - in un modello di proprietà individuale, la perdita di un proprietario è costoso in termini di tempo necessario per qualcun altro di prendere in consegna, ma l'evento è abbastanza raro che il costo ammortizzato è basso.

Piuttosto, penso che la proprietà collettiva del codice porti direttamente al codice di alta qualità. Questo è per due ragioni molto semplici. In primo luogo, perché la dolorosa verità è che alcuni dei tuoi programmatori non sono bravi come gli altri, e se possiedono il codice, quel codice sarà scadente; dare ai tuoi programmatori migliori l'accesso migliorerà. In secondo luogo, revisione del codice: se tutti possiedono il codice, tutti possono rivederlo e migliorarlo; anche i bravi programmatori scrivono codice sub-par se lasciato ai propri dispositivi.

Dico questo sulla base dell'esperienza del mio attuale progetto. Il nostro obiettivo è di praticare la proprietà collettiva, ma ci sono alcuni bit del sistema che sono diventati specializzati - io e un altro ragazzo sono proprietari di fatto del sistema di compilazione, per esempio, c'è un ragazzo che sta facendo la maggior parte del lavoro sui feed di dati in arrivo , un altro ragazzo che lavora all'importazione di immagini e così via. In molte di queste aree (! Particolare, devo confessare, nella mia zona), la qualità del codice ha gravemente sofferto - ci sono errori, malintesi, kludges e hack che non semplicemente sopravvivere l'attenzione di altre persone nella squadra <. / p>

Ho notato che si potrebbe ottenere alcuni dei benefici della proprietà del codice collettiva avendo proprietà codice individuale in cui la proprietà di un particolare bit di mosse di codice tra diversi programmatori regolarmente (per esempio, ogni tre mesi, o ogni rilascio - forse anche ogni iterazione?). Un equivalente di programmazione della rotazione delle colture. Potrebbe essere divertente. Non ho intenzione di provarlo da solo, però.

Non penso che la proprietà del codice del team sia tanto importante quanto il fatto che più contributori comprendano l'architettura di base dei sottosistemi prevalenti.

Ad esempio, abbiamo un paio di ragazzi del nostro team che creano pagine Web amministrative per i nostri prodotti server. Abbiamo creato un motore di script lato server personalizzato in modo che potessimo chiamare le funzioni C essenziali sul server direttamente dai nostri script java o html. Penso che sia più importante che i nostri ragazzi del "web" capiscano come utilizzare questo motore in contrasto con l'essere comproprietari delle altre applicazioni della pagina web.

Penso che tu prenda la proprietà individuale del codice nel momento in cui la scrivi e poi la riveli al team. In questo modo tutti si assumono la responsabilità e contribuiscono. 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 pulizia dopo gli altri.

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

Jim, sono con te su quell'uno al 100%. Sono nel bel mezzo della stessa battaglia nel mio posto di lavoro - ed è per questo che sono incappato 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 codificare la qualità rispetto alla proprietà e alla responsabilità.

Un esempio tratto dalla vita reale lo illustra bene. quale ti prenderesti cura di più: il tuo prato privato o il parco della comunità? Piuttosto ovvio.

Questo, comunque, non deve necessariamente essere scambiato per "flessibilità della squadra". Significa semplicemente che quando una persona possiede qualcosa che possiede, e se solo per il giorno.

Per me dipende dalle dinamiche della tua squadra.

Ad esempio, se hai una squadra che non è unificata per standard, peer review, test metodico, o se hai una squadra in cui i livelli di competenza variano selvaggiamente tra i membri, potrebbe essere utile cercare una nozione più strong di proprietà del codice con una mentalità modulare più black-box.

Mancanza di questo, ad esempio, l'interfaccia attentamente progettata conforme ai principi SOLID potrebbe essere rapidamente rovinata da qualcuno che non sa nemmeno "SOLID" significa e vuole aggiungere nuove funzioni eclettiche all'interfaccia per "convenienza" ", per esempio Questo è di gran lunga il peggiore.

Potresti anche trattare con colleghi sciatti la cui idea di correggere un bug è quella di correggere il sintomo senza capire il problema di root (es: cercando di rispondere a un crash report semplicemente mettendo rimedi nel codice solo per nascondere il bug e trasferire gli effetti collaterali mortali a qualcun altro). In tal caso, non è tanto male come sabotare il design dell'interfaccia e puoi proteggere le tue intenzioni con test unitari attentamente costruiti.

La soluzione ideale è stringere la tua squadra in un punto in cui questa nozione di paternità e proprietà non è più così importante. La revisione paritetica 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 peer review e in realtà il fatto che tutti si conformano a uno standard sono semplicemente senza speranza e porteranno molti critici irrimediabilmente inesperti nel mix. Direi che la proprietà del codice o la proprietà del team assumono una priorità più strong si baserà sulla capacità del tuo team di eseguire effettivamente un'efficace revisione tra pari e in realtà lasciare uscire tutti come se ne beneficiassero (sia in termini di revisione stessa e avvicinandosi di più alla mentalità e agli standard come risultato). Nelle squadre grandi, sciolte 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 l'esclusiva proprietà sembrerà una sciocca nozione.

In questi tipi di scenari lontani dall'ideale, questa nozione di proprietà del codice può effettivamente aiutare. Sta cercando di risolvere il caso peggiore, ma può essere d'aiuto nel caso in cui il lavoro di squadra sia generalmente senza speranza per mettere una barriera attorno al codice di un autore. In tal caso, diminuisce il lavoro di squadra, ma ciò può essere migliore se il "lavoro di gruppo" porta solo a un passo-passo.