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

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

Dipende

C'è motivo di credere che prendere la posizione che ogni programmatore dovrebbe conoscere ogni riga di codice è fuorviata.

Se ipotizziamo per un momento che qualcuno con una profonda comprensione di un pezzo di codice apporti modifiche 5 volte più velocemente di qualcuno che non lo conosce affatto (non un gigantesco atto di fede nella mia esperienza) e richiede circa un mese di esperienza di codifica per ottenere una buona comprensione di un modulo di dimensioni significative (anche non irragionevole), quindi possiamo eseguire alcuni numeri (completamente falsi e fittizi):

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

Diciamo che il programmatore A ottiene 1 unità di lavoro al giorno. In 4 settimane di 5 giorni lavorativi lui / lei può ottenere 20 unità di lavoro fatte.

Quindi il programmatore B, partendo da 0,2 unità di lavoro al giorno e terminando con 0,96 unità di lavoro al suo 20 ° giorno (il 21 ° giorno sono all'altezza del programmatore A), realizzerà 11,6 unità di lavoro nello stesso periodo di 20 giorni. Durante quel mese il programmatore B ha raggiunto il 58% di efficienza rispetto al programmatore A. Tuttavia, ora hai un altro programmatore che conosce quel modulo e anche il primo.

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

Quindi considera questo scenario: stessi programmatori, stesso progetto (A sa tutto e B non ne sa niente). 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, 1,4 unità di lavoro eseguite su ciascun modulo. Totale (A + B) è di 6.4 unità di lavoro per modulo. Questo perché B passa la maggior parte del tempo senza alcuna abilità con il modulo su cui stanno lavorando.

In questa situazione, è più ottimale avere B focus su un sottoinsieme più piccolo di moduli. Se B si concentra su solo 25 moduli, ottengono 10 giorni ciascuno, per un totale di 3,8 unità di lavoro su ciascuno. Il programmatore A potrebbe quindi trascorrere 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 ottenuto quando A e B diffondono il lavoro in modo uniforme.

Man mano che riduciamo l'ambito dei moduli su cui lavora B, otteniamo un'efficienza ancora maggiore (fino a un certo punto).

Formazione

Vorrei anche obiettare che qualcuno che non sa tanto di un modulo interromperà la persona che molto di più di qualcuno con più esperienza. Quindi questi numeri sopra non tengono conto del fatto che più il tempo B trascorre sul codice che non capiscono, più il tempo che A impiega a fare domande, ea volte A deve aiutare a correggere o risolvere ciò che ha fatto B. Addestrare qualcuno è un'attività che richiede tempo.

Soluzione ottimale

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

• Quanto è grande la tua squadra? Ha senso che tutti abbiano una formazione trasversale su ogni parte, o se abbiamo una squadra di 10 persone, possiamo semplicemente 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 è il fatturato del tuo dipendente? Se passi dei dipendenti a una media ogni 3 anni, e ci vuole più tempo per conoscere davvero ogni angolo del sistema, allora non sarà abbastanza lungo perché l'addestramento possa ripagarsi.
• Hai davvero bisogno di un esperto per diagnosticare un problema? Un sacco di persone usano la scusa, "cosa succede se quella persona va in vacanza", ma sono stato chiamato in numerose volte per diagnosticare un problema in un sistema con cui non ho avuto esperienza. Potrebbe essere vero che la persona esperta potrebbe trovarla 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 che in 5 ore o il mondo finirà. Devi valutare questi rischi.

Ecco perché penso che "dipende". Non vuoi dividere 20 moduli tra due programmatori a metà (10 ciascuno), perché non hai flessibilità, ma non vuoi nemmeno attraversare i 10 programmatori su tutti e 50 i moduli perché perdi un sacco di efficienza e non hai bisogno di così tanto ridondanza.

È un'idea orribile . Potrebbe essere più veloce a breve termine, ma incoraggia codice mal scritto e difficile da comprendere, poiché solo il programmatore che lo ha scritto è responsabile della sua manutenzione. Quando qualcuno lascia la compagnia o va in vacanza, l'intero piano viene messo a soqquadro. Inoltre rende molto difficile allocare i carichi di lavoro; cosa succede quando due errori urgenti si presentano con il codice che un codificatore "possiede"?

Dovresti codificare come una squadra . Le persone saranno naturalmente assegnate compiti e si concentreranno su alcune aree, ma condividere il carico di lavoro e lavorare insieme dovrebbero essere incoraggiati, non scoraggiati.

Dipende da quale sia il dominio del problema.

Se si tratta di cose generali (ad esempio azioni semplici di CRUD, ecc.), quindi sono d'accordo con Tom Squires (chiunque dovrebbe essere in grado di lavorarci sopra e modificarlo).

Tuttavia ...

Se la soluzione in questione richiede esperienza nel dominio (è stato investito molto tempo in passato o sono necessarie molte ricerche prima dell'implementazione, poiché in questo è necessario elencare un requisito di lavoro come conoscenza specialistica che non tutti hanno nel progetto), quindi un proprietario dovrebbe sicuramente essere assegnato a quella parte del codice. Detto questo, chiunque dovrebbe essere in grado di apportare modifiche a esso se necessario, ma dovrebbe sempre essere esaminato dalla persona che possiede quell'area del progetto.

Non vuoi avere l'intera squadra (o un numero di persone nel team) che ricerca e apprende lo stesso argomento (cicli sprecati). Assegna un proprietario, ma chiedi loro di documentare i loro apprendimenti e 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 mucchio di debito tecnico . La linea di fondo è che due teste sono quasi sempre meglio di una. Perché? Perché a meno che tu non sia un idiota, sai che non sei un programmatore perfetto e non intendi afferrare tutti gli errori che fai. Questo è il motivo per cui hai bisogno di un team - più occhi che guardano lo stesso codice da diverse prospettive.

Si riduce a una cosa: disciplina . Quanti programmatori solitari sai chi sono veramente disciplinati nel loro stile di codifica? Quando non si codifica con disciplina, si prendono scorciatoie (perché si "aggiusterà in seguito") e la manutenibilità del codice ne risente. Sappiamo tutti che "dopo" non verrà mai. Fatto : è più difficile prendere scorciatoie quando sei immediatamente responsabile nei confronti dei tuoi pari in una squadra. Perché? Perché le tue decisioni saranno messe in discussione ed è sempre più difficile giustificare scorciatoie. Risultato finale? Produci codice migliore e più gestibile che è anche più robusto.

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

Un compromesso sarebbe avere almeno 2 proprietari per ogni area di codice. Poi 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, che è un po 'più efficiente.

Non avere le stesse 2 (o 3) persone che lavorano insieme tutto il tempo. Sposta le coppie per aree diverse, quindi la conoscenza viene condivisa anche inavvertitamente quando si lavora con una persona diversa in un'area di programma correlata.

Sì, è leggermente più efficiente, a breve termine. E qui finisce il beneficio. Questo non si avvicina nemmeno al superamento dei costi.

Cosa succede quando è in vacanza, o inaspettatamente malato, o esce, o viene colpito dal bus proverbiale? Cosa succede quando vuoi flettere le risorse per ottenere un lavoro più veloce di un altro? Quanto possono essere efficaci le recensioni di codice? Come può un manager, in particolare uno che non si trova nella base di codice, sapere se lo sviluppatore sta lavorando sodo o si stacca la lana dagli occhi? Chi noterà se il debito tecnico inizia a scoppiare?

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

Questo non vuol dire che, in 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 lavorare quelle persone. Nessun individuo dovrebbe possedere qualcosa.

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

• esperienza : qualcuno del team ha una conoscenza dettagliata di un determinato campo; questa conoscenza è indipendente dall'implementazione specifica di quel dominio nel progetto
• leadership : sebbene il lavoro di costruzione del progetto possa essere condiviso tra molti sviluppatori; la roadmap e le decisioni immediate su importanti dettagli di implementazione sono nelle mani di un particolare membro del team o solo di alcuni membri del team.
• codice egoless : il modo particolare in cui il progetto viene implementato non dipende dagli stili di codifica, dalle pratiche o dalle conoscenze di un particolare sviluppatore del team; e aderendo rigorosamente a uno stile di codifica ben noto oa una specifica ben mantenuta, ogni nuovo membro della squadra 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 particolare esperto di quel dominio. Gli esperti, sebbene forse rari e preziosi, sono ancora essenzialmente intercambiabili; un contabile fiscale esperto è utile per un progetto software di pianificazione fiscale come un altro, dal punto di vista della conoscenza del dominio. Il problema diventa uno di quanto l'esperto sia in grado di trasferire le sue conoscenze al progetto.

Quando l'argomento è puramente di leadership, il successo del progetto dipende principalmente dalla coerenza e dall'intuizione delle decisioni prese dal leader del progetto; sebbene tendiamo a favorire i lead di progetto che hanno esperienza nel settore o che sono provati come leader di progetto, 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 rapidamente eseguita dal team. Se funziona correttamente; molte decisioni non devono essere "fatte" dal lead del progetto perché il team comprende già quali decisioni saranno prese.

Non penso che la domanda riguardasse davvero il codice senza ego, ma è difficile parlare della proprietà del codice senza discutere anche di quanto sia importante questo problema. Mantenere 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 accadrebbe se la intera squadra dovesse essere sostituita? Se il progetto è messo in dubbio perché dipende da alcuni giocatori 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 siano necessari per far progredire il progetto significa che potresti non lavorare nel modo più efficiente possibile se gli sviluppatori fossero più coinvolti.

La proprietà del codice tende a impedire il refactoring, creare colli di bottiglia dello sviluppo e causare problemi di ego quando il codice presenta problemi che dovrebbero essere affrontati.

Raccomando di consultare gli autori del codice prima di cambiarlo, anche se il codice standard elevato dovrebbe essere sufficientemente documentato, testato, collaudato e collaudato per rendere questo ridondante, non può comunque far male avere un altro parere.

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

I motivi per cui ciò è negativo:

• Se il proprietario del codice prende una vacanza e qualche grosso bug compare nella loro roba, sarà molto difficile e dispendioso in termini di tempo cercare di imparare il codice E correggere il bug
• Se il proprietario del codice lascia la società, i loro progetti saranno gravemente ritirati dal momento in cui tutta la conoscenza del patrimonio e della tribù è appena uscita dalla porta
• La documentazione è scarsa. Se io sono l'unica persona a codificarci, perché dovrei documentarlo? Il problema è legato al fatto che qualsiasi documentazione che è costretta a essere creata sarà anche povera perché nessuno ne saprà abbastanza sul codice per dire veramente se la documentazione è completa o addirittura accurata.
• Le guerre sante di codice possono facilmente innescarsi quando tutti hanno la loro piccola sandbox, come altri hanno menzionato che questo può diventare davvero stupido molto rapidamente. Dove questo è un problema, quando due persone devono lavorare insieme, nessuno dei due è abituato a compromettere mai qualcosa.
• A causa del punto precedente, le abilità di lavoro di squadra non si formano mai - le persone non devono mai lavorare con gli altri.
• I feudi possono facilmente formare, piccoli regni fatti di sacche di rifiuti che non comprano nulla della compagnia. Non sai che stanno succedendo finché non è troppo tardi perché il modulo o lo strumento X è responsabilità di Bob, e guai a chi dovrebbe anche informarsi su cosa sta facendo Bob nel suo codice .
• Le revisioni del codice e le revisioni tra colleghi soffrono perché nessuno sa nulla del codice. Se non conosci il codice, non puoi individuare i luoghi che non sono corretti e limitarti 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 in ciò che scriviamo, ma è una cosa di gruppo, come quando la tua squadra vince una partita difficile. Qualsiasi dipendente che lavora per la società possiede il codice in modo uguale e, nel corso del proprio lavoro, è autorizzato a modificarlo in qualsiasi modo a suo piacimento per svolgere il proprio lavoro, ovvero per trasmettere gli obiettivi dell'azienda.

I più grandi sono davvero i problemi del personale e la documentazione. Quella persona se ne andrà un giorno e il ragazzo spingerà il programma a sinistra per alcune settimane.

L'approccio migliore è che tutti abbiano familiarità con ogni parte della base di codice (o una mezza dozzina di parti o così se sono davvero grandi e diverse) al punto che possono

• Correzione di eventuali difetti in quell'area
• Aggiungi 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, o l'esperto di defacto può farcela. Ho lavorato in gruppi in cui questo era il caso e ha funzionato molto bene. Non solo non c'erano nessuno degli aspetti sopra elencati, il personale era molto più prevedibile dal momento che non eravamo alla ricerca di esperti.

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

Vedi Numero di camion alias Fattore di bus

bus factor (also known as truck factor, or bus/truck number) is a measurement of the concentration of information in individual team members. The bus factor is the total number of key developers who would need to be incapacitated (as by getting hit by a bus/truck) to send the project into such disarray that it would not be able to proceed; the project would retain information (such as source code) with which no remaining team member is familiar. A high bus factor means that many developers would need to be removed before the project would necessarily fail.

"Getting hit by a bus" could take many different forms. This could be a person taking a new job, having a baby, changing their lifestyle or life status, or literally getting hit by a bus: the effect would be the same...

Come molte altre cose, è un grande "dipende". Se è un rigoroso "nessun altro può lavorare sul codice", probabilmente sta andando male. Se è "il proprietario deve fare una revisione del codice prima di accettare una modifica", è mediocre, a seconda di quanto è disposto il proprietario ad accettare cambiamenti esterni.

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

Per verificare, il "numero di camion" è definito semplicemente come "quanti membri del team, nel peggiore dei casi, potrebbero essere investiti da un camion prima che la conoscenza necessaria per eseguire alcuni compiti critici venga persa per il team."

È naturale, e un po 'da incoraggiare, che gli sviluppatori si concentrino sulle sotto-discipline; se tutti dovessero sapere tutto ciò che ha a che fare con il progetto, nulla verrebbe fatto perché tutti imparerebbero cosa hanno fatto gli altri, perché funziona e come può essere cambiato senza romperlo. Inoltre, se gli sviluppatori sono spenti a fare cose diverse in aree diverse è meno probabile che le modifiche si scontrino. Quindi è generalmente bene avere due o tre sviluppatori o coppie di sviluppo che funzionano principalmente in un particolare sottosistema del progetto e conoscerlo bene.

Tuttavia, se si suppone che una sola persona tocchi una particolare riga di codice, allora quando quel ragazzo si licenzia, viene licenziato, va in vacanza o finisce in ospedale, e quella linea di codice è dimostrata come la causa di un bug che deve essere corretto, qualcun altro deve entrare e capire il codice. Se nessun altro, tranne il ragazzo che lo ha scritto, l'ha mai visto, ci vorrà del tempo per raggiungere un livello di comprensione che consenta allo sviluppatore di apportare le modifiche che risolvono il bug senza fare di più. TDD può aiutare, ma solo dicendo allo sviluppatore hanno fatto il cambiamento "sbagliato"; di nuovo, lo sviluppatore deve capire quali test stanno esercitando quale codice per assicurarsi che i test in errore non stiano cercando di fare affermazioni sbagliate.

Non lo prendo all'estremo, ma preferisco la responsabilità del codice . Scrivi codice rotto, dovresti correggerlo. Questo può essere fatto a livello individuale, di coppia o di gruppo. Impedisce il passaggio del tuo pasticcio a qualcun altro per ripulire. Questo vale anche per le modifiche.

Il carico di lavoro e i problemi di pianificazione sovrascriveranno questo. Sarebbe sciocco tenere a bada un bug importante perché il colpevole è in vacanza di due settimane.

L'obiettivo non è quello di far giocare la tua squadra "il gioco della colpa" o portare a termine un errore (non sono uguali in ogni caso). Basala su chi ha controllato il codice in ultimo o chiedi a un supervisore di prendere la decisione e assegnarla a qualcuno invece di esaminare ogni parte di ogni riga di codice.

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