Tempo assegnato alle revisioni del codice

Se stai facendo recensioni di codice

• Quanto tempo dedichi alle revisioni del codice, rispetto all'implementazione?
• Quante modifiche sono state sottoposte a revisione del codice?
• pensi che sia troppo / dovrebbe essere di più?

Ci sono studi sull'efficacia?

[modifica] grazie a tutti per le risposte, è difficile scegliere un "vincitore" per una domanda del genere, ci sono molte informazioni preziose anche nelle altre risposte.

Nel mio lavoro abbiamo la seguente procedura per la revisione del codice. Finora ha funzionato bene per noi e lo abbiamo trovato molto efficiente in termini di tempo, soprattutto in termini di ore-uomo. In realtà non abbiamo alcun tempo specifico assegnato alle recensioni. Ogni commit o unione nel trunk deve essere riesaminato e il tempo necessario affinché il revisore lo approvi.

Modifica: il tempo necessario, ovviamente, dipende dall'entità del cambiamento. Le piccole funzionalità e le correzioni di bug richiedono pochi minuti. Grandi nuove funzionalità, refactoring o modifiche che interessano molte parti del sistema possono richiedere mezza giornata per la revisione e un altro giorno per affrontare tutti i problemi che sorgono di conseguenza.

Per far funzionare questo sistema è fondamentale impegnarsi spesso nel trunk, in modo che le modifiche siano di dimensioni gestibili. Non vuoi avere la situazione quando devi rivedere il valore di un anno del codice di qualcuno.

Per quanto riguarda gli studi, il software Smart Bear ti invierà gratuitamente un piccolo libro, Best Kept Secrets of Peer Code Review . Comprende numerosi articoli su vari aspetti della revisione del codice, inclusi studi su quanto tempo dovrebbero impiegare e quanto siano efficaci.

Nel nostro progetto, ogni modifica significativa al sistema viene esaminata dal team leader o insieme a un altro sviluppatore che sarà il "consumatore" principale del nuovo modulo. Parliamo su skype e utilizziamo Rudel in Emacs (un plug-in per l'editing collaborativo, in pratica consente a diversi utenti di modificare lo stesso file dal vivo), o TypeWith.me (Piratepad), o uno di noi condivide il suo schermo su skype.

È difficile quantificarlo, perché le modifiche banali, come nuove visualizzazioni, pagine, ecc. Non vengono riviste. Esaminiamo nuovi moduli, importanti aggiornamenti e refactoring. Per quanto riguarda le grandi modifiche, la revisione del codice può richiedere dal 10% al 30% del tempo, ma ne vale la pena.

Posso dire che la programmazione in coppia, quando 2 programmatori modificano lo stesso file contemporaneamente, non solo siedono sullo stesso computer, è molto meglio della solita pratica in ufficio di sedersi alle spalle.

Per cose semplici come convenzioni di denominazione ed errori di ambito, utilizziamo i nostri strumenti automatici propri o open source (jslint, pylint, pyflakes, pep8). E non limitiamo impegni e spinte: usiamo Mercurial che ha diramazioni e fusioni molto facili (devo dire, più facili che in Git). I bug non sono una questione di revisione del codice.

Facciamo riunioni di gruppo in cui vengono annunciati i cambiamenti e le novità, ma non tutti prestano davvero attenzione. Probabilmente dovremmo fare un po 'più di recensioni di codice.

Non esiste una risposta giusta o sbagliata a questo. Ma come molti prima di me hanno suggerito - se la revisione del codice viene eseguita da un membro del team esterno [metodo altamente raccomandato] potrebbe ammontare a circa il 30% al 35% dello sforzo di sviluppo. Ma se ciò viene fatto da un membro del team di progetto interno che faceva parte del team di sviluppo [non raccomandato], questo può essere completato in circa il 20% del tempo impiegato per lo sviluppo.

Nota: mi sono imbattuto in questo thread durante la ricerca di qualcos'altro e ho pensato di poter aggiungere un valore qui. A proposito, tutta questa stima dello sforzo di cui sopra si basa sulla mia esperienza di lavoro come manager di coinvolgimento in più progetti. Spero che sia d'aiuto.

Ogni organizzazione e base di codice è diversa, quindi è difficile ottenere un valore a livello di settore.
Se sei davvero serio, allora dovresti iniziare a raccogliere le metriche. Vale a dire fare la revisione del codice fino a quando non viene eseguita in modo soddisfacente, inclusa la rilavorazione. Inizia a raccoglierlo in un database (LOC, complessità del codice, linguaggio di programmazione, ora ecc.). Quindi raccogliere anche le metriche sulla percentuale di difetti durante il test. Finché è possibile ridurre questa revisione del codice dovrebbe pagare da sola. Se il difetto ritorna dai test, raccogliere le metriche su quanto tempo è stato impiegato per correggere i difetti. Crea questi dati nella tua organizzazione, crea linee di base e puoi prevederli in modo abbastanza accurato. I termini per cercare ulteriori studi sono Costo della qualità e Costo della scarsa qualità.

L'unica avvertenza è che questo può iniziare a diventare burocratico e dipende dalla cultura dell'organizzazione.