Se stai facendo revisioni del codice
Ci sono studi sull'efficacia?
[modifica] grazie a tutti per le risposte, è difficile scegliere un "vincitore" per una tale domanda, ci sono molte informazioni preziose anche nelle altre risposte.
Al mio lavoro abbiamo il seguente procedura per le revisioni del codice. Ha funzionato bene per noi finora, e abbiamo trovato che fosse molto efficiente nel tempo, specialmente in termini di ore uomo. Non abbiamo davvero alcun tempo specifico assegnato alle recensioni. Ogni commit o fusione con il trunk deve essere rivisto, e ci vuole tutto il tempo necessario affinché il revisore lo ritenga ok.
Modifica: Il tempo necessario, ovviamente, dipende dalla grandezza del cambiamento. Piccole funzionalità e correzioni di bug richiedono pochi minuti. Le nuove grandi funzioni, i refactoring o le modifiche che interessano molte parti del sistema possono richiedere una mezza giornata per la revisione e un altro giorno per risolvere tutti i problemi che si presentano di conseguenza.
Per far funzionare questo sistema è fondamentale eseguire il commit sul trunk spesso, 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.
Riguardo agli studi, il software Smart Bear ti invierà un piccolo libro, Best Tenete segreti dei peer code review , gratuitamente. Ha una serie di articoli su vari aspetti della revisione del codice, compresi gli studi su quanto tempo dovrebbero prendere e quanto sono efficaci.
Nel nostro progetto, ogni modifica significativa al sistema viene esaminata dal leader del team o insieme a un altro sviluppatore che sarà il principale "consumatore" del nuovo modulo. Parliamo su skype e usiamo Rudel in Emacs (un plugin per l'editing collaborativo, in pratica consente a più utenti di modificare lo stesso file live), o TypeWith.me (Piratepad), o uno di noi condivide il suo schermo in skype.
È difficile quantificarlo, perché le modifiche banali, come nuove visualizzazioni, pagine, ecc. non vengono riviste. Esaminiamo i nuovi moduli, i principali aggiornamenti e i refactoring. Per quanto riguarda i grandi cambiamenti, la revisione del codice può richiedere dal 10% al 30% di tempo, ma vale la pena.
Posso dire che la programmazione in coppia, quando 2 programmatori modificano lo stesso file allo stesso tempo, non solo siedono allo stesso computer, è molto meglio della solita pratica in ufficio di sedersi dietro la spalla.
Per cose semplici come le convenzioni di denominazione e gli errori di ambito usiamo i nostri strumenti automatici propri o open source (jslint, pylint, pyflakes, pep8). E non limitiamo i commit e spinge: usiamo Mercurial che ha una ramificazione e fusione molto semplice (devo dire, più facile che in Git). I bug non sono una questione di revisione del codice.
Facciamo riunioni di team in cui vengono annunciati i cambiamenti e le novità, ma non tutti prestano attenzione. Probabilmente dovremmo fare un po 'più di revisione del codice.
Non c'è 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 questo viene fatto da un membro del team di progetto interno che faceva parte del team di sviluppo [non raccomandato], questo può essere completato in approssimativamente entro il 20% del tempo impiegato per lo sviluppo.
Nota: ho trovato questo thread quando cercavo qualcos'altro e ho pensato di poter aggiungere qualche valore qui. Btw, tutto questo sopra la stima dello sforzo si basa sulla mia esperienza lavorativa come responsabile del coinvolgimento in più progetti. Spero che sia d'aiuto.
Ogni organizzazione e base di codice è diversa, quindi è difficile ottenere un valore per il settore.
Se sei veramente serio, dovresti iniziare a raccogliere le metriche. Cioè Esegui la revisione del codice fino a quando non viene eseguito in modo soddisfacente, inclusa la rielaborazione. Iniziare a raccogliere questo in un database (LOC, complessità del codice, linguaggio di programmazione, ora ecc.). Quindi raccogli anche le metriche sulla frequenza dei difetti durante il test. Finché è possibile ridurre questa revisione del codice dovrebbe pagare da solo. Se il difetto ritorna dai test, raccogli le metriche su quanto tempo è stato impiegato per correggere i difetti. Costruisci questi dati nella tua organizzazione, crea linee di base e puoi prevederlo in modo abbastanza accurato. I termini per cercare ulteriore apprendimento sono il costo della qualità e il costo della scarsa qualità.
L'unico avvertimento è che questo può iniziare a diventare burocratico e dipende dalla cultura dell'organizzazione.
Leggi altre domande sui tag code-reviews time-management