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

Poiché non è chiaro dalla tua domanda, voglio solo sottolineare che un flusso di lavoro di gatekeeper non è assolutamente necessario con git. È popolare con i progetti open source a causa del gran numero di contributori 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 ad occuparsi comunque del codice rotto di altri programmatori. Se tutti hanno accesso push, la build sarà interrotta e i migliori programmatori tendono a essere quelli che spesso integrano e rintracciano i colpevoli quando le cose si rompono.

La cosa su chiunque abbia accesso push è che quando qualcosa si rompe, tutti chi tira ottiene una build rotta fino a quando il commit offendente non viene ripristinato o corretto. Con un flusso di lavoro del gatekeeper, è interessato solo il gatekeeper. In altre parole, stai influenzando solo uno dei tuoi migliori programmatori anziché tutti.

Potrebbe accadere che la qualità del codice sia abbastanza elevata e il rapporto costi-benefici di un gatekeeper non valga ancora la pena, ma non trascurare i costi familiari. Solo perché sei abituato a quella perdita di produttività non significa che non sia stato sostenuto.

Inoltre, non dimenticare di esplorare le opzioni ibride. È molto facile con git impostare un repository a cui chiunque può spingere, quindi avere un gatekeeper come uno sviluppatore senior, un tester o persino un server di integrazione continua automatizzata decidere se e quando una modifica lo fa diventare un secondo repository più stabile. In questo modo puoi ottenere il meglio da entrambi i mondi.

Ho lavorato a un lavoro in cui i check-in erano limitati ai soli lead del team (e i lead del team non potevano controllare il proprio codice). Questo è servito come il nostro meccanismo per far rispettare le revisioni del codice, in gran parte a causa di una serie di incidenti in cui cattivi commit sono entrati nella base di codice anche attorno a check-in gated e analisi statiche.

Da un lato, ha fatto il suo lavoro. Un certo numero di cattivi commit sono stati trovati prima che entrassero nella base di codice (e prontamente dimenticati per una settimana o giù di lì fino a quando qualcuno non li ha incappati). Ciò ha causato meno interruzioni nel codice base. Inoltre, potrei respingere alcune cose di formattazione / struttura prima che diventassero debito tecnologico; prendere alcuni bug prima che diventassero bug. E mi ha dato una grande sensazione per quello che stava facendo il mio team.

D'altro canto, mi ha fatto andare spontaneamente in infuriati brutti colpi quando il mio cambio di 3 linee impiegava 4 ore per commettere, perché dovevo rintracciare un altro piombo e convincerli a fare il commit. Mi ha spinto a eseguire 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 fatti.

In genere non lo raccomanderei tranne negli ambienti più bisognosi. Fare recensioni e commettere non era poi così male. Avere il mio processo dipendente dai capricci degli altri era però esasperante. Se non ti puoi fidare dei tuoi sviluppatori per il check-in del codice, cerca sviluppatori migliori.

No. Chiunque dovrebbe essere in grado di impegnarsi.

Se hai problemi con il commit di bug, non è il criterio di controllo del codice sorgente che è sbagliato. Sono gli sviluppatori che non riescono a garantire che ciò che lui / lei commette funziona. Quindi quello che devi fare è definire chiare linee guida su cosa impegnare e quando.

Un'altra grande cosa si chiama unit test;)

C'è un'alternativa però.

a) Se si utilizza il controllo della versione distribuita, è possibile creare un repository principale al quale possono essere fatte solo le richieste di 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 subversion e simili potresti usare branch dove ogni dev deve creare patch per farlo entrare nel ramo principale.

Dovresti dare un'occhiata a progetti come Gerrit che consente a tutti gli sviluppatori di spingere il loro codice nella sezione "recensione" e una volta che gli sviluppatori senior / lead sono soddisfatti di questi cambiamenti, possono trasferirli in master / release.

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

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

No, è un cattivo uso del tuo talento migliore. Immagina una casa editrice che prende gli autori di maggior successo e li fa fare editing; cattiva idea.

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

1. Nessuno - Voglio vedere ogni riga di codice prima di controllarlo.
2. Alcuni - Fammi sapere cosa stai facendo e fornirò un feedback
3. Most - Vai a fare il tuo lavoro e chiedi solo aiuto quando necessario.

I vantaggi di liberare il tuo talento:

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

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

is the review worth the productivity hit?

Dipende dal "saldo" del team e dal modo in cui vengono impostate le recensioni. Entrambe sono questioni di gestione e lavoro di squadra, nessuna quantità di magia tecnologica di controllo della versione (centralizzata o distribuita) può avere un'influenza sostanziale su questo.

Se fatto male , il colpo di produttività ovviamente eliminerà tutti i vantaggi della revisione; la risposta è però non far cadere l'idea delle recensioni ma a scoprire come farlo bene .

Un approccio per scoprire se le tue recensioni sono OK è quello di utilizzare strumento di monitoraggio dei problemi per tenere traccia del tempo speso per le recensioni (alcuni strumenti di revisione del codice lo consentono anche). Se scopri che le recensioni impiegano molto tempo, dedica qualche sforzo alla ricerca delle ragioni e dei modi per migliorare le cose. Inoltre, non sarebbe male avere 1: 1s regolare con il team membri per scoprire potenziali problemi con le revisioni del codice.

Se i "migliori" programmatori del team sono costretti a trascorrere ore a scavare tra immondizie incomprensibili prodotte da codificatori scadenti, la soluzione è quella di licenziare i crap-maker, non di fare appello alla tecnologia VCS.

• ^{In uno dei progetti precedenti mi è stato assegnato il compito di rivedere le modifiche al codice eseguite da membri del team con prestazioni insufficienti, in un componente che impiegava quasi un'ora per creare ed eseguire test. Ho iniziato a leggere i diff e quando ho notato un cambiamento incomparabile, ho semplicemente finito di rivedere, ho postato i commenti necessari e ho chiesto al management di garantire che ulteriori richieste di revisione vengano fornite con la conferma scritta che il loro codice viene compilato. Non ci sono state "richieste di revisione" da quando il ragazzo se n'è andato.}

Dall'altra parte, quando la squadra è ragionevolmente equilibrata, 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 e non ci distraevo. Sono stati scoperti bug tramite la revisione e ci sono stati dibattiti sullo stile di codifica e sulle scelte di progettazione, ma questo sembrava solo ... normale .

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

• <sup>- Oh l'integrazione di questo cambiamento è stata molto ritardata perché il revisore si è improvvisamente ammalato, che sfortuna.
  - Ciao! Hell-lo-o-o, hai mai pensato di avere backup per trattare casi come questi?</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 debiti tecnici più tardi.

Se ci sono molti programmatori, è possibile delegare l'attività di revisione del codice ai tenenti e fare in modo che lo sviluppatore principale effettui le proprie modifiche (quasi) indiscutibilmente. 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 codice errato. Vedrà abbastanza rapidamente che J.Random scrive un buon codice che deve solo verificare le decisioni architetturali mentre lo stagista scrive un codice errato che deve essere esaminato riga per riga prima della fusione. Il feedback generato in questo modo ridurrà gli oneri di manutenzione lungo la linea e darà un'esperienza di prima mano su ciò che lo stagista effettivamente impara e dovrebbe essere tenuto in compagnia. Tirare e unire un ramo da un altro git repo richiede letteralmente una (coppia) dozzina di secondi, in genere la lettura dei titoli dei messaggi di commit richiederà più tempo, quindi dopo che so chi può essere considerato affidabile per scrivere codice buono il codice di altre persone è un non -emissione.

La revisione del codice non richiede necessariamente l'attenzione solo dei tuoi migliori programmatori. IMO, dovrebbe essere una cosa informale. Solo un secondo parere o un secondo paio di occhi su un pezzo di codice da un non-novellino prima che venga controllato in produzione. Aiuta a mitigare le principali sviste mentre aiuta anche le persone a migliorare la codifica come mestiere essendo esposta ad altre prospettive di sviluppo.

Una sorta di lite per la programmazione delle paia meno odiosa. In altre parole, non dovrebbe richiedere molto tempo e non dovresti aspettare qualcuno per ore. Qualunque cosa nel tuo processo di sviluppo che coinvolga persone in attesa di cose è uno spreco di denaro e paralizzante per lo slancio / morale, IMO.

Se la revisione del codice avesse lo scopo di fermare il 99,5% dei bug prima che entrassero nella tua base di codice, in primo luogo, non ci sarebbe alcun reale punto di controllo della versione sofisticato. Detto questo, git all'inizio è intimidatorio, ma l'uso generale di base non è così complicato ed è altamente configurabile. Dovresti riuscire a fermarti per qualche ora per insegnare a tutti come usarlo. Tutti si impegnano Tutti tranne i debuttanti più pazzi rivedere fino a quando non dimostrano esperienza in qualcosa.

Finché le modifiche inviate sono state esaminate dai "migliori programmatori", chiunque dovrebbe essere autorizzato a inviare il codice. L'unica persona che dovrebbe avere la possibilità di applicare il controllo su un repository è Release Engineer, se tale persona esiste.

Personalmente, sarei molto 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 del male e i bravi programmatori apprezzeranno questo. Forse c'è una certa riluttanza a partecipare alle recensioni perché a loro non piace l'idea di "programmatori minori" che criticano il loro codice. È semplicemente troppo brutto. Sarebbero molto più propensi a smettere se la linea del codice è costantemente infestata e passano invece il loro tempo a ripulire le sottomissioni a metà degli altri.

Sì, la recensione vale la pena. Non sono sicuro che ci sia un problema di produttività se il processo di revisione è proporzionale per i seguenti motivi:

• Mantiene i programmatori onesti - se sai che verrà esaminato, le persone prenderanno meno scorciatoie
• Aiuta i nuovi programmatori a imparare da più programmatori esperti
• Aiuta a trasferire le conoscenze specifiche del dominio
• Review è un'altra porta in cui possono essere trovati e risolti bug e potenziali problemi

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

Detto questo, penso sia ragionevole che tu abbia qualcuno che è responsabile di alcuni rami chiave, come un ramo di rilascio. In questo caso, immagino che tutti possano utilizzare il repository git, ma solo alcune persone si uniscono nel ramo di rilascio. Non sono sicuro che ci sia un modo per far rispettare questo in git, ma dovrebbe essere possibile farlo per processo e semplicemente controllando che nessun altro ci abbia controllato.

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

do good programmers quit if a significant portion of their job is to review other people's code?

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

Should your best programmers have to check everyone else's code into source control?

Assolutamente NO. È sicuramente uno spreco del loro tempo, ad eccezione di alcune logiche critiche che devono essere in stato solido come il rock .

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