* Sistema * proprietario del codice: è un modo efficiente? [chiuso]

C'è un nuovo sviluppatore nel nostro team. Una metodologia agile è in uso presso la nostra azienda. Ma lo sviluppatore ha un'altra esperienza: ritiene che particolari parti del codice debbano essere assegnate a determinati sviluppatori. Quindi, se uno sviluppatore avesse creato una procedura o un modulo di programma, sarebbe considerato normale che tutte le modifiche alla procedura / al modulo fossero fatte solo da lui.

Tra i lati positivi, presumibilmente con l'approccio proposto risparmiamo tempo di sviluppo comune, perché ogni sviluppatore conosce bene la sua parte del codice e corregge rapidamente. L'aspetto negativo è che gli sviluppatori non conoscono completamente il sistema.

Pensi che l'approccio funzionerà bene per un sistema di medie dimensioni (sviluppo di un sito di social network)?

Come molte di queste domande, penso che la risposta sia:

Dipende

C'è motivo di ritenere che assumere la posizione secondo cui ogni programmatore dovrebbe conoscere ogni riga di codice sia errato.

Se supponiamo per un momento che qualcuno con una profonda conoscenza di un pezzo di codice effettuerà le modifiche 5 volte più velocemente di qualcuno che non lo conosce affatto (non un grande salto di fiducia nella mia esperienza) e ci vorrà circa un mese di esperienza di codifica per ottenere una comprensione davvero buona di un modulo di dimensioni significative (anche non irragionevole) quindi possiamo eseguire alcuni numeri (completamente falsi e fittizi):

• Programmatore A: ha una profonda comprensione
• Programmatore B: nessuno

Diciamo che il programmatore A esegue 1 unità di lavoro al giorno. In 4 settimane di 5 giorni lavorativi può svolgere 20 unità di lavoro.

Quindi il programmatore B, a partire da 0,2 unità di lavoro al giorno e terminando con 0,96 unità di lavoro nel suo 20 ° giorno (il 21 ° giorno sono bravi come il programmatore A), realizzerà 11,6 unità di lavoro nella stessa Periodo di 20 giorni. Durante quel mese il programmatore B ha raggiunto un'efficienza del 58% rispetto al programmatore A. Tuttavia, ora hai un altro programmatore che conosce quel modulo e il primo.

Certo, su un progetto di dimensioni decenti, potresti avere ... 50 moduli? Quindi familiarizzare con tutti loro richiede circa 4 anni e ciò significa che il programmatore di apprendimento lavora, in media, con un'efficienza del 58% rispetto al programmatore A ... hmmm.

Quindi considera questo scenario: stessi programmatori, stesso progetto (A sa tutto e B non ne conosce nessuno.) Diciamo che ci sono 250 giorni lavorativi all'anno. Supponiamo che il carico di lavoro sia distribuito casualmente sui 50 moduli. Se dividiamo entrambi i programmatori in modo uniforme, A e B ottengono entrambi 5 giorni lavorativi su ciascun modulo. A può fare 5 unità di lavoro su ciascun modulo, ma B ottiene, secondo la mia piccola simulazione Excel, solo 1,4 unità di lavoro su ciascun modulo. Il totale (A + B) è di 6,4 unità di lavoro per modulo. Questo perché B trascorre la maggior parte del tempo senza alcuna abilità con il modulo su cui stanno lavorando.

In questa situazione, è più ottimale concentrarsi B su un sottoinsieme di moduli più piccolo. Se B si concentra su soli 25 moduli, ottengono 10 giorni su ciascuno, per un totale di 3,8 unità di lavoro su ciascuno. Il programmatore A potrebbe quindi passare 7 giorni ciascuno sui 25 moduli su cui B non sta lavorando e 3 giorni ciascuno lavorando sugli stessi di B. La produttività totale varia da 6,8 a 7 unità per modulo, con una media di 6,9, e questo è significativamente più alto rispetto alle 6,4 unità per modulo che abbiamo fatto quando A e B hanno distribuito il lavoro in modo uniforme.

Quando restringiamo l'ambito dei moduli su cui B lavora, otteniamo ancora più efficienza (fino a un certo punto).

Formazione

Direi anche che qualcuno che non sa molto di un modulo interromperà la persona che fa molto di più di qualcuno con più esperienza. Quindi questi numeri sopra non tengono conto del fatto che più tempo B dedica al codice che non capiscono, più tempo A impiega facendo domande e talvolta A deve aiutare a correggere o risolvere ciò che B ha fatto. Formare qualcuno è un'attività che richiede tempo.

Soluzione ottimale

Ecco perché penso che la soluzione ottimale debba basarsi su domande come:

• Quanto è grande la tua squadra? Ha senso avere tutti cross training su ogni parte, o se abbiamo un team di 10 persone, possiamo solo assicurarci che ogni modulo sia conosciuto da almeno 3 persone? (Con 10 programmatori e 50 moduli, ogni programmatore deve conoscere 15 moduli per ottenere una copertura 3x.)
• Come sta il fatturato dei tuoi dipendenti? Se si consegnano i dipendenti in media ogni 3 anni e ci vuole più tempo per conoscere davvero ogni angolo del sistema, non saranno abbastanza a lungo da consentire alla formazione di ripagarsi.
• Hai davvero bisogno di un esperto per diagnosticare un problema? Molte persone usano la scusa, "cosa succede se quella persona va in vacanza", ma sono stato chiamato più volte per diagnosticare un problema in un sistema con cui non avevo esperienza. Potrebbe essere vero che la persona esperta potrebbe trovarlo molto più velocemente, ma ciò non significa che non puoi vivere senza di loro per una settimana o due. Pochi sistemi software sono così mission-critical che il problema deve essere diagnosticato in 1 ora invece di 5 ore, altrimenti il ​​mondo finirà. Devi soppesare questi rischi.

Ecco perché penso "dipende". Non vuoi dividere 20 moduli tra due programmatori proprio al centro (10 ciascuno), perché non hai flessibilità, ma non vuoi nemmeno formare 10 programmatori su tutti i 50 moduli perché perdi molto efficienza e non è necessaria molta ridondanza.

È un'idea terribile . Può essere più veloce a breve termine, ma incoraggia il codice mal documentato e difficile da capire, poiché solo il programmatore che lo ha scritto è responsabile della sua manutenzione. Quando qualcuno lascia la compagnia o va in vacanza l'intero piano diventa confuso. Inoltre, è molto difficile allocare i carichi di lavoro; cosa succede quando due bug urgenti escono con il codice che un programmatore "possiede"?

Dovresti programmare come una squadra . Alle persone verranno naturalmente assegnati compiti e si concentreranno su determinate aree, ma la condivisione del carico di lavoro e la collaborazione dovrebbero essere incoraggiate, non scoraggiate.

Dipende da quale sia il dominio del problema.

Se è roba generale (cioè semplici azioni CRUD, ecc.), Sono d'accordo con Tom Squires (chiunque dovrebbe essere in grado di lavorarci su e modificarlo).

Tuttavia ...

Se la soluzione in questione richiede competenze di dominio (molto tempo è stato investito in passato o molta ricerca deve essere effettuata prima dell'implementazione, poiché in questo è qualcosa che dovresti elencare in un requisito di lavoro come conoscenza specializzata che non tutti nel progetto lo hanno), quindi un proprietario dovrebbe sicuramente essere assegnato a quella parte del codice. Detto questo, chiunque dovrebbe essere in grado di apportare modifiche ad esso, se necessario, ma dovrebbe sempre essere rivisto dalla persona che possiede quell'area del progetto.

Non vuoi che tutta la tua squadra (o un certo numero di persone della squadra) ricerca e apprenda la stessa materia (cicli sprecati). Assegna un proprietario, ma chiedi loro di documentare i loro apprendimenti e i loro progetti e magari farli condurre sessioni di formazione informali (o formali, non importa) sulla tecnologia.

Questa è un'idea orribile . Ho lavorato in un'azienda che ha utilizzato questo approccio ed è praticamente una ricetta per un sacco di debito tecnico . La linea di fondo è che due teste sono quasi sempre meglio di una. Perché? Perché se non sei un idiota, sai che non sei un programmatore perfetto e non colpirai tutti gli errori che commetti. Ecco perché hai bisogno di una squadra: più occhi guardano lo stesso codice da diverse prospettive.

Si riduce a una cosa: la disciplina . Quanti programmatori solitari conosci che sono veramente disciplinati nel loro stile di programmazione? Quando non codifichi con disciplina, prendi scorciatoie (perché "riparerai più tardi") e la manutenibilità del codice ne risente. Sappiamo tutti che "dopo" non arriva mai. Fatto : è più difficile prendere scorciatoie quando sei immediatamente responsabile verso i tuoi pari in una squadra. Perché? Perché le tue decisioni saranno messe in discussione ed è sempre più difficile giustificare le scorciatoie. Risultato finale? Produci codice migliore, più gestibile e anche più robusto.

Il vantaggio è che non tutti hanno bisogno di ricercare e comprendere tutto. Lo svantaggio è quello che rende ogni persona necessaria per la propria area di codice e nessun altro sa come mantenerla.

Un compromesso sarebbe quello di avere almeno 2 proprietari per ogni area di codice. Quindi qualcuno può andare in vacanza, fare un nuovo lavoro o andare in pensione e c'è ancora qualcuno che conosce il codice (e può addestrare la nuova seconda persona). Non tutti hanno bisogno di imparare tutto, il che è un po 'più efficiente.

Non avere le stesse 2 (o 3) persone che lavorano insieme sempre. Scambia coppie per aree diverse, quindi le conoscenze vengono condivise inavvertitamente quando si lavora con una persona diversa su un'area del programma correlata.

Sì, è leggermente più efficiente, a breve termine. E lì finiscono i benefici. Ciò non si avvicina nemmeno al superamento del costo.

Cosa succede quando è in vacanza, o inaspettatamente malato, o se ne va, o viene colpito dal proverbiale autobus? Cosa succede quando si desidera flettere le risorse per ottenere un lavoro più velocemente di un altro? Quanto possono essere efficaci le revisioni del codice? Come può un manager, in particolare uno che non è nella base di codici, sapere se lo sviluppatore sta lavorando sodo o si sta tirando la lana sugli occhi? Chi noterà se il debito tecnico inizia ad aumentare?

Nella mia esperienza, le persone a cui piace lavorare in questo modo sono cacciatori di gloria nella migliore delle ipotesi, pigri nella peggiore delle ipotesi. A loro piace essere l'unica persona a cui puoi andare con un determinato problema e gli piace che il loro codice rimanga privato. E spesso amano programmare velocemente, senza riguardo per la leggibilità.

Questo non vuol dire che, su un team di 50 sviluppatori, tutti dovrebbero conoscere tutto il codice, ma un team di 5-7 dovrebbe possedere un modulo abbastanza grande da far funzionare quelle persone. Nessun individuo dovrebbe possedere nulla.

Ci sono almeno tre problemi che le altre risposte sottolineano; ma vorrei provare a trattarli entrambi insieme. I due problemi sono:

• competenza : qualcuno nel team ha una conoscenza dettagliata di un particolare campo; questa conoscenza è indipendente dalla specifica implementazione di quel dominio nel progetto
• leadership : sebbene il lavoro di costruzione del progetto possa essere condiviso da molti sviluppatori; la tabella di marcia, nonché le decisioni immediate su importanti dettagli di implementazione sono nelle mani di un determinato membro del team o solo di alcuni membri del team.
• codice egoless : il modo particolare in cui viene implementato il progetto non dipende dagli stili di codifica, dalle pratiche o dalla conoscenza di alcun particolare sviluppatore nel team; e dalla stretta aderenza a uno stile di codifica ben noto o una specifica ben mantenuta, ogni nuovo membro del team ha le stesse possibilità di comprendere i come e i perché del progetto come gli sviluppatori esperti.

Quando l'argomento è puramente di competenza, il successo del progetto può dipendere da un elevato livello di conoscenza del dominio; ma non dipende dalla conoscenza di un esperto specifico di quel dominio. Gli esperti, sebbene forse rari e preziosi, sono ancora essenzialmente intercambiabili; un contabile fiscale esperto è utile a un progetto software di pianificazione fiscale come un altro, dal punto di vista delle sue conoscenze di dominio. Il problema diventa uno dei modi in cui l'esperto è in grado di trasferire le sue conoscenze al progetto.

Quando l'argomento è puramente di leadership, il successo del progetto dipende principalmente dalla coerenza e comprensione delle decisioni prese dal leader del progetto; anche se tendiamo a favorire i lead di progetto che hanno esperienza nel settore o che sono comprovati come project leader, questo a volte è secondario rispetto al ruolo. Il "leader" potrebbe cambiare di giorno in giorno se le decisioni prese sono coerenti da un caso all'altro e ogni decisione viene eseguita rapidamente dalla squadra. Se funziona correttamente; molte decisioni non devono essere "prese" dal responsabile del progetto perché il team comprende già quali decisioni verranno prese.

Non penso che la domanda riguardasse davvero il codice senza ego, ma è difficile parlare della proprietà del codice senza discutere anche dell'importanza di questo problema. Il mantenimento di un progetto è probabilmente la parte più ampia del ciclo di sviluppo. Il modo per capire questo problema è chiedersi cosa succederebbe se alcuni sviluppatori dovessero lasciarlo immediatamente. Cosa succederebbe se l' intera squadra dovesse essere sostituita? Se il progetto viene messo in dubbio perché dipende da alcuni attori chiave, allora si corre un alto rischio di fallimento. Anche se non perdi mai un singolo membro del team, il semplice fatto che uno o alcuni sviluppatori sono necessari per far avanzare il progetto significa che potresti non lavorare nel modo più efficiente possibile se più sviluppatori fossero coinvolti.

La proprietà del codice tende a prevenire il refactoring, crea strozzature di sviluppo e causa problemi di ego quando il codice ha problemi che dovrebbero essere affrontati.

Consiglio vivamente di consultare gli autori del codice prima di modificare, anche se un codice di alto livello dovrebbe essere sufficientemente documentato, testato sull'unità, testato sull'integrazione e testato sul sistema per rendere questo ridondante, non può ancora far male avere un'altra opinione.

Questo è negativo per molte ragioni, ho lavorato in un negozio dove hanno cercato di passare da questo a qualcosa di più ragionevole ed è stato brutto.

I motivi per cui questo è negativo:

• Se il proprietario del codice si prende una vacanza e compaiono alcuni grossi bug nelle loro cose, sarà molto difficile e dispendioso in termini di tempo provare a imparare il codice E correggere il bug
• Se il proprietario del codice lascia l'azienda, i suoi progetti saranno gravemente arretrati poiché tutta l'eredità e la conoscenza tribale sono appena uscite dalla porta
• La documentazione è scadente. Se sono l'unica persona a codificarlo, perché dovrei documentarlo? Correlato è il problema che probabilmente anche la documentazione che viene forzata a essere creata sarà scarsa perché nessuno saprà abbastanza del codice per dire veramente se la documentazione è completa o addirittura accurata.
• Le guerre sacre di codice possono facilmente accendersi quando ognuno ha la propria sandbox, poiché altri hanno già detto che può diventare davvero stupido molto rapidamente. Dove questo è un problema è quando due persone devono lavorare insieme, nessuno dei due è abituato a scendere a compromessi su nulla.
• A causa del punto sopra, le abilità del lavoro di squadra non si formano mai - le persone non devono mai lavorare con gli altri.
• I feudi possono facilmente formarsi, piccoli regni fatti da sacche di rifiuti che non comprano nulla alla compagnia. Non sai che stanno accadendo fino a quando non è troppo tardi perché il modulo o lo strumento X è responsabilità di Bob, e guai a te che dovresti anche chiedere cosa Bob sta facendo nel suo codice.
• Le revisioni del codice e le revisioni tra pari soffrono perché nessuno sa nulla del codice. Se non conosci il codice, non puoi individuare i luoghi che non sono corretti e si limitano a commentare solo la formattazione del testo e le convenzioni di denominazione.
• E se lavori per me ... la società possiede il codice, non tu. Siamo orgogliosi di ciò che facciamo e di ciò che realizziamo e di ciò che scriviamo, ma è una cosa di gruppo, come quando la tua squadra vince una partita difficile. Ogni dipendente che lavora per l'azienda possiede il codice allo stesso modo, e nel corso del proprio lavoro è autorizzato a modificarlo in qualsiasi modo per fare il proprio lavoro che è quello di inoltrare gli obiettivi dell'azienda.

I più grandi sono in realtà le questioni relative al personale e la documentazione. Quella persona partirà un giorno, e ragazzo spingerai il programma a sinistra per alcune settimane.

L'approccio migliore è far conoscere a tutti ogni parte della base di codice (o una mezza dozzina di parti se è davvero grande e diversificata) al punto da poter

• Correggi qualsiasi difetto in quella zona
• Aggiungi nuove funzionalità o miglioramenti minori o moderati

Ogni persona tende a conoscere un po 'di più su alcune cose rispetto ad altre, quindi per i problemi difficili due o tre possono unirsi insieme, o l'esperto defacto può affrontarlo. Ho lavorato in gruppi in cui questo era il caso e ha funzionato davvero bene. Non solo non c'erano nessuno dei contro sopra elencati, ma il personale era molto più prevedibile poiché non cercavamo esperti.

Il pro alla proprietà esclusiva del codice è che il "proprietario del codice" può probabilmente fare le cose più velocemente di altri, ma questo vale solo se tutti sono "proprietari del codice" in progetti non sovrapposti. In altre parole, se le persone ruotano attorno al vantaggio del "solo proprietario del codice" scompare.

Vedi il numero di camion noto anche come fattore di bus

il fattore bus (noto anche come fattore camion o numero bus / camion ) è una misurazione della concentrazione di informazioni nei singoli membri del team. Il fattore bus è il numero totale di sviluppatori chiave che dovrebbero essere inabilitati (come se fossero colpiti da un autobus / camion) per mandare il progetto in un tale disordine che non sarebbe in grado di procedere; il progetto manterrebbe informazioni (come il codice sorgente ) con cui nessun membro del team rimanente ha familiarità. Un fattore bus elevato significa che molti sviluppatori dovrebbero essere rimossi prima che il progetto fallisca necessariamente.

"Essere colpiti da un autobus" potrebbe assumere molte forme diverse. Questa potrebbe essere una persona che prende un nuovo lavoro, ha un bambino, cambia il suo stile di vita o il suo stato di vita o viene letteralmente investita da un autobus: l'effetto sarebbe lo stesso ...

Come per molte cose, è un grande "dipende". Se si tratta di un rigoroso "nessun altro può lavorare sul codice", probabilmente sta andando a male. Se è "il proprietario deve fare una revisione del codice prima di accettare una modifica", diventa mediocre, a seconda della volontà del proprietario di accettare la modifica esterna.

Lo svantaggio è grave; il "numero di camion" della tua squadra diventa praticamente 1.

Per rivedere, il "numero di camion" è definito semplicemente come "quanti membri della squadra, nel peggiore dei casi, potrebbero essere colpiti da un camion prima che le conoscenze necessarie per eseguire alcune attività critiche vengano perse nella squadra".

È naturale, e un po 'da incoraggiare, che gli sviluppatori si concentrino su sotto-discipline; se tutti dovessero sapere tutto ciò che riguarda il progetto, nulla verrebbe fatto perché tutti imparerebbero ciò che tutti gli altri avevano fatto, perché funziona e come può essere cambiato senza romperlo. Inoltre, se gli sviluppatori non fanno cose diverse in aree diverse, è meno probabile che i cambiamenti si scontrino. Quindi è generalmente utile avere due o tre sviluppatori o coppie di sviluppatori che lavorano principalmente in un particolare sottosistema del progetto e lo conoscono bene.

Tuttavia, se si suppone che una sola persona tocchi una determinata riga di codice, quando quel ragazzo esce, viene licenziato, va in vacanza o finisce in ospedale, e quella riga di codice viene dimostrata come causa di un bug che deve essere risolto, qualcun altro deve entrare e comprendere il codice. Se nessun altro, tranne il ragazzo che l'ha scritto, lo avrà mai visto, ci vorrà del tempo per arrivare a un livello di comprensione che consenta allo sviluppatore di apportare la modifica che corregge il bug senza farne di più. TDD può aiutare, ma solo dicendo allo sviluppatore di aver apportato la modifica "sbagliata"; di nuovo, lo sviluppatore deve capire quali test stanno esercitando quale codice per assicurarsi che i test falliti non stiano provando a fare affermazioni sbagliate.

Non lo prendo all'estremo, ma preferisco la responsabilità del codice . Scrivi un codice non funzionante, dovresti risolverlo. Questo può essere fatto a livello individuale, di coppia o di squadra. Impedisce di passare il disordine a qualcun altro per ripulire. Questo vale anche per i cambiamenti.

I problemi di carico di lavoro e pianificazione lo sovrascriveranno. Sarebbe sciocco evitare di risolvere un grosso problema perché il colpevole è in vacanza di due settimane.

L'obiettivo non è far giocare la tua squadra "il gioco della colpa" o prendere troppi conteggi di bug (non sono comunque tutti uguali). Basalo su chi ha controllato il codice per ultimo o chiedi a un supervisore di prendere la decisione e assegnarlo a qualcuno invece di esaminare ogni parte di ogni riga di codice.

I programmatori migliori probabilmente finiscono per correggere un sacco di codice di altre persone, indipendentemente da come lo assegni.