I tuoi migliori programmatori dovrebbero controllare il codice di tutti gli altri nel controllo del codice sorgente?

Una delle differenze tra svn e git è la capacità di controllare l'accesso al repository. È difficile confrontare i due perché c'è una differenza di prospettiva su chi dovrebbe essere autorizzato a commettere cambiamenti!

Questa domanda riguarda l'uso di git come repository centralizzato per un team di un'azienda da qualche parte. Supponiamo che i membri del team abbiano livelli di abilità variabili, come nella maggior parte delle aziende.

Git sembra presumere che i tuoi unici programmatori migliori (i più produttivi, i più esperti) siano affidabili per il check-in del codice. In tal caso, stai prendendo il loro tempo lontano dalla scrittura del codice per rivedere il codice di altre persone al fine di controllarlo. Questo paga? Voglio davvero concentrare questa domanda su qual è il miglior uso del tempo del tuo miglior programmatore, non sulle migliori pratiche di controllo della versione in generale . Un corollario potrebbe essere: i bravi programmatori si ritirano se una parte significativa del loro lavoro consiste nel rivedere il codice di altre persone? Penso che entrambe le domande si riducano a: la recensione vale il colpo di produttività?

Dal momento che non è chiaro dalla tua domanda, voglio solo sottolineare che un flusso di lavoro gatekeeper non è affatto richiesto con git. È popolare tra i progetti open source a causa del gran numero di collaboratori non attendibili, ma non ha molto senso all'interno di un'organizzazione. Hai la possibilità di dare a tutti l'accesso push se vuoi.

Ciò che le persone trascurano in questa analisi è che i bravi programmatori passano molto tempo a gestire comunque il codice non funzionante di altri programmatori. Se tutti hanno accesso push, la build si romperà e i migliori programmatori tendono ad essere quelli che spesso integrano e rintracciano i colpevoli quando le cose si rompono.

La cosa su cui tutti hanno accesso push è che quando qualcosa si rompe, chiunque tira ottiene una build interrotta fino a quando il commit offensivo non viene ripristinato o risolto. Con un flusso di lavoro gatekeeper, è interessato solo il gatekeeper. In altre parole, stai interessando solo uno dei tuoi migliori programmatori anziché tutti.

Si potrebbe scoprire che la qualità del codice è piuttosto elevata e il rapporto costi-benefici di un gatekeeper non ne vale ancora la pena, ma non trascurare i costi familiari. Solo perché sei abituato a quella perdita di produttività non significa che non sia sostenuta.

Inoltre, non dimenticare di esplorare le opzioni ibride. Con git è molto semplice configurare un repository a cui chiunque può fare affidamento, quindi un gatekeeper come uno sviluppatore senior, un tester o persino un server di integrazione continua automatizzato decide se e quando una modifica lo trasforma in un secondo repository più stabile. In questo modo puoi ottenere il meglio da entrambi i mondi.

Ho lavorato in un lavoro in cui i check-in erano limitati ai soli lead di team (e i lead di team non potevano controllare il proprio codice). Questo è stato il nostro meccanismo per imporre la revisione del codice, in gran parte a causa di una serie di incidenti in cui cattivi impegni sono entrati nella base di codice anche attorno a check-in controllati e analisi statiche.

Da un lato, ha fatto il suo lavoro. Un certo numero di cattivi impegni sono stati trovati prima di entrare nella base di codice (e prontamente dimenticati per circa una settimana fino a quando qualcuno non si è imbattuto in loro). Ciò ha causato meno interruzioni nella base di codice. Inoltre, potrei respingere alcune cose di formattazione / struttura prima che diventassero debiti tecnologici; catturare alcuni bug prima che diventino bug. E mi ha dato un'ottima sensazione per quello che stava facendo la mia squadra.

D'altra parte, mi ha fatto andare spontaneamente in rabbia omicida quando il mio cambio di 3 linee ha richiesto 4 ore per impegnarsi a causa di dover rintracciare un altro vantaggio e convincerli a fare il commit. Mi ha spinto a fare commit molto meno frequenti rispetto alle best practice, e occasionalmente ha portato a problemi nel tentativo di tenere traccia delle modifiche allo sviluppatore che li ha eseguiti.

Non lo consiglierei generalmente se non negli ambienti più bisognosi. Effettuare le recensioni e gli impegni non è stato poi così male. Avere il mio processo dipendente dai capricci degli altri è stato esasperante. Se non puoi fidarti dei tuoi sviluppatori per fare il check-in del codice, ottieni sviluppatori migliori.

No. Chiunque dovrebbe essere in grado di impegnarsi.

Se si riscontrano problemi con errori commessi, non è errata la politica di controllo del codice sorgente. Sono gli sviluppatori che non riescono a assicurarsi che ciò che commette funzioni. Quindi, ciò che devi fare è definire linee guida chiare su cosa impegnare e quando.

Un'altra cosa grandiosa si chiama unit test;)

C'è un'alternativa però.

a) Se si utilizza il controllo della versione distribuita, è possibile creare un repository principale a cui è possibile effettuare solo richieste pull. In questo modo tutti gli sviluppatori possono ottenere il controllo delle versioni del proprio codice mentre si ottiene il controllo del ramo principale.

b) In sovversione e simili puoi usare i rami in cui ogni sviluppatore deve creare patch per farlo entrare nel ramo principale.

Dovresti dare un'occhiata a progetti come Gerrit che consente a tutti gli sviluppatori di inserire il loro codice nel ramo di "revisione" e una volta che gli sviluppatori senior / lead sono soddisfatti di questi cambiamenti, possono spingerli in master / release.

Se non sono felici, possono lasciare commenti accanto a una riga di codice, chiedere patch aggiornate ecc.

In questo modo chiunque abbia un cambiamento in sospeso può farlo uscire non appena è pronto e solo le persone qualificate (con i giusti privilegi +2 in Gerrit) saranno in grado di spingere quel codice per testarlo e successivamente per la produzione.

No, è un cattivo uso del tuo miglior talento. Immagina una casa editrice che prende i suoi autori di maggior successo e li fa fare il montaggio; cattiva idea.

Dovrebbero esserci recensioni di codice, ma ciò non significa che sia sempre un Sr. che controlla un codice jr. Alla fine, tutti i membri del team dovrebbero raggiungere il livello in cui possono contribuire al codice con una guida minima. Passano attraverso i tre livelli di fiducia:

1. Nessuno: voglio vedere ogni riga di codice prima di registrarlo.
2. Alcuni - Fammi sapere cosa stai facendo e fornirò feedback
3. La maggior parte: vai a fare il tuo lavoro e chiedi aiuto solo quando è necessario.

Vantaggi di liberare il tuo talento:

• concentrarsi sul design
• coinvolgimento nell'impostazione di standard di codifica e strategie di applicazione (senza farlo manualmente da soli)
• affrontare i difficili problemi di codifica
• fornire tutoraggio (senza aver approvato ogni riga di codice)

Ci sono sviluppatori interessati a un percorso di gestione che potrebbero preferire non programmare tutto il giorno; lascia in pace gli altri.

la recensione vale il colpo di produttività?

Dipende dal "bilancio" della squadra e dalla modalità di impostazione delle recensioni. Entrambe sono questioni di gestione e lavoro di squadra, nessuna quantità di magia tecnologica di controllo versione (centralizzata o distribuita) può avere un'influenza sostanziale su questo.

Se fatto male , il colpo di produttività ovviamente ucciderà tutti i benefici della revisione; la risposta è però non abbandonare l'idea delle recensioni ma scoprire come farlo nel modo giusto .

Un approccio per scoprire se le tue recensioni sono OK è quello di utilizzare lo strumento di tracciamento dei problemi per tenere traccia del tempo speso nelle recensioni (alcuni strumenti di revisione del codice lo consentono anche). Se scopri che le recensioni richiedono molto tempo, investi qualche sforzo nella ricerca dei motivi e dei modi per migliorare le cose. Inoltre, non sarebbe male avere 1: 1 regolari con i membri del team per scoprire potenziali problemi con le revisioni del codice.

Se i "migliori" programmatori del team sono costretti a passare ore a scavare tra rifiuti incomprensibili prodotti da programmatori schifosi, la soluzione è licenziare i produttori di merda, non fare appello alla tecnologia VCS.

• ^{In uno dei progetti passati mi è stato assegnato il compito di rivedere le modifiche al codice eseguite da un membro del team permanentemente poco performante, in un componente che impiegava quasi un'ora per costruire ed eseguire i test. Ho iniziato a leggere le differenze e quando ho notato una modifica non compilabile, ho semplicemente finito la revisione, pubblicato i commenti necessari e chiesto alla direzione di assicurarsi che ulteriori richieste di revisione arrivino con una conferma scritta che il loro codice viene compilato. Non ci sono state "richieste di revisione" da quando e presto il ragazzo è partito.}

D'altra parte, quando il team è abbastanza equilibrato, le revisioni del codice sono divertenti ed educative. Nel mio progetto precedente, avevamo un requisito per la revisione del codice al 100% e non ci volle molto tempo né era fonte di distrazione. Ci sono stati dei bug scoperti attraverso la revisione e ci sono stati dibattiti sullo stile di codifica e sulle scelte di design, ma è sembrato semplicemente ... normale .

Se le modifiche al codice vengono bloccate per giorni ... settimane dall'arrivo al QA per i test "a causa delle recensioni", studiare i trucchi di VCS sarebbe il modo meno probabile per risolvere questo problema. Invece si dovrebbe concentrare meglio i propri sforzi sulla scoperta di problemi nel modo in cui è organizzato il processo di revisione.

• <sup>- Oh l'integrazione di questo cambiamento è stata molto ritardata perché il recensore si è ammalato improvvisamente, che sventura.
  - Ciao! Diavolo, hai mai pensato di avere dei revisori di backup per gestire casi del genere?</sup>

Sì. Ma solo se stai parlando del controllo del codice sorgente distribuito. Con centralizzato - dipende.

Se ci sono solo pochi programmatori, ci vuole poco tempo. Certamente meno delle correzioni che saranno necessarie per rimuovere bug e debito tecnico in seguito.

Se ci sono molti programmatori, è possibile delegare il compito di revisione del codice effettivo ai luogotenenti e fare in modo che lo sviluppatore principale esegua le loro modifiche (quasi) senza dubbio. Funziona con il kernel Linux, non penso che ci siano progetti software più grandi ...

Ancora una volta, se il progetto è piccolo, il lead vedrà rapidamente chi fornisce un buon codice e chi produce un codice errato. Vedrà abbastanza rapidamente che J.Random scrive un buon codice che deve solo verificare le decisioni sull'architettura, mentre il tirocinante scrive un codice errato che deve essere rivisto riga per riga prima della fusione. Il feedback generato in questo modo ridurrà l'onere della manutenzione lungo la linea e offrirà un'esperienza di prima mano su tutto ciò che il tirocinante effettivamente impara e dovrebbe essere tenuto in compagnia. L'estrazione e la fusione di un ramo da un altro gitrepository richiede letteralmente una (coppia) dozzina di secondi, in genere la lettura dei titoli dei messaggi di commit richiederà più tempo, quindi dopo che so di chi ci si può fidare per scrivere un buon codice che unisce il codice di altre persone non è un problema.

La revisione del codice non richiede necessariamente l'attenzione solo dei migliori programmatori. IMO, dovrebbe essere una cosa informale. Solo una seconda opinione o un secondo paio di occhi su un pezzo di codice di un non novellino prima che venga verificato in produzione. Aiuta a mitigare le sviste più importanti, aiutando nel contempo le persone a migliorare la codifica come mestiere esponendosi ad altre prospettive degli sviluppatori.

Una specie di lite di programmazione a coppia meno odiosa. In altre parole, non dovrebbe volerci molto e non dovresti aspettare qualcuno per ore. Qualunque cosa nel tuo processo di sviluppo che coinvolga le persone in attesa di cose è uno spreco di denaro e paralizzante per slancio / morale, IMO.

Se la revisione del codice avesse lo scopo di bloccare il 99,5% dei bug prima che entrassero nella tua base di codice in primo luogo, non ci sarebbe alcun reale punto di controllo sofisticato della versione. Detto questo, inizialmente Git è intimidatorio ma l'uso generale di base non è così complicato ed è altamente configurabile. Dovresti essere in grado di fermarti per alcune ore per insegnare a tutti come usarlo. Tutti si impegnano. Tutti tranne i principianti più rumorosi riesaminano fino a quando non dimostrano competenza in qualcosa.

Finché le modifiche inviate sono state riviste dai "migliori programmatori", a chiunque dovrebbe essere consentito di inviare il codice. L'unica persona che dovrebbe avere la capacità di imporre il controllo su un repository è l'Ingegnere del rilascio, se quella persona esiste.

Personalmente, sarei incazzato se dovessi controllare il codice di altre persone.

Alcuni input sulla tua modifica: No, non dovrebbero. Le recensioni sono un male necessario, fanno più bene che male e i bravi programmatori lo apprezzeranno. Forse c'è riluttanza a partecipare alle recensioni perché a loro non piace l'idea di "programmatori minori" che criticano il loro codice. È semplicemente un peccato. Sarebbero molto più propensi a smettere se la codeline è costantemente buggy e invece passano il loro tempo a ripulire dopo gli invii mezzo forno di altre persone.

Sì, la recensione ne vale la pena. Non sono sicuro che si verifichi un aumento della produttività se il processo di revisione è proporzionale per i seguenti motivi:

• Mantiene i programmatori onesti: se sai che verrà rivista, le persone prenderanno meno scorciatoie
• Aiuta i nuovi programmatori a imparare da più programmatori esperti
• Aiuta a trasferire conoscenze specifiche del dominio
• Review è un altro portale in cui è possibile trovare e correggere bug e potenziali problemi

Non consentendo a tutti i programmatori di utilizzare il controllo del codice sorgente, perdono la capacità di tenere traccia delle modifiche, annullare gli errori e visualizzare una cronologia ragionevole delle modifiche. Non sono sicuro che vorresti che solo i tuoi "migliori" programmatori potessero effettuare il check-in per git.

Detto questo, penso che sia ragionevole che tu abbia qualcuno che si occupa di determinati rami chiave, come un ramo di rilascio. In questo caso, immagino che tutti possano usare il repository git, ma solo alcune persone si uniscono al ramo di rilascio. Non sono sicuro che ci sia un modo per imporre questo in Git, ma dovrebbe essere possibile farlo per processo e solo controllando che nessun altro abbia verificato.

La fusione nel ramo di rilascio potrebbe essere effettuata dai programmatori "migliori", o più probabilmente da persone competenti dopo che è stata effettuata una revisione sufficiente.

i bravi programmatori si ritirano se una parte significativa del loro lavoro consiste nel rivedere il codice di altre persone?

Se non stanno godendo il lavoro e sono costretti a fare questa attività, allora SÌ. È molto probabile che accada. Poiché trovare il prossimo lavoro interessante per un buon sviluppatore non è una grande sfida al giorno d'oggi.

I tuoi migliori programmatori dovrebbero controllare il codice di tutti gli altri nel controllo del codice sorgente?

Assolutamente no. È sicuramente una perdita di tempo, fatta eccezione per alcune logiche critiche che devono essere in uno stato solido come una roccia .

Tuttavia, gli sviluppatori junior o con esperienza probabilmente dovrebbero essere in un periodo di prova per una qualità del codice , solo per essere al sicuro e assicurarsi che il loro codice segua le linee guida di sviluppo del team, almeno per un paio di settimane prima di ottenere il privilegio di impegnarsi.