Qual è il tuo processo di revisione e approvazione del codice e quali sono i suoi vantaggi / svantaggi? [chiuso]

Le revisioni del codice possono essere immensamente utili per identificare potenziali bug e fare in modo che gli sviluppatori rispettino gli standard di codifica aziendale. Tuttavia, è importante avere chiare linee guida su ciò che è ed è non per la revisione. A mio avviso, uno standard di codifica scritto accessibile tramite un browser web è un must. E a tutti i membri del team dovrebbe essere data la possibilità di fornire suggerimenti su ciò che accade nello standard. Quando un revisore segnala un difetto, deve citare la sezione dello standard che il codice viola e fornire un collegamento ipertestuale ad esso.

Avere uno standard scritto e richiedere che i revisori lo citino per ogni oggetto che contrassegnano come un difetto ha un paio di effetti importanti:

1. Mantiene le recensioni troppo personali. I revisori stanno semplicemente controllando la conformità con uno standard concordato, non "bashing" lo sviluppatore il cui codice è in fase di revisione.
2. Gli sviluppatori possono rivedere il codice molto più rapidamente quando hanno una "lista di controllo" di cose da cercare.

Una volta ho lavorato per un'azienda che ha deciso di implementare un flusso di lavoro che utilizzava Gerrit per le revisioni del codice e richiesta una revisione prima che il codice potesse essere impegnato nel ramo dev - una decisione che ero strongmente a favore di allora. E lo sono ancora. Sfortunatamente, non avevamo uno standard di codifica scritto. Una manciata di membri senior del team pensavano che questo sarebbe stato "eccessivo" o "troppo restrittivo" e riteneva che uno standard de facto esistesse all'interno della cultura aziendale che "tutti già sanno". Prevedibilmente, le recensioni sono state trasformate in un dibattito senza fine sullo spazio bianco e sul posizionamento delle parentesi graffe, e discussioni riscaldate si sono svolte regolarmente su argomenti che non avevano nulla da fare, in realtà, con la qualità del codice o l'esecuzione della missione dell'azienda.

Questo è il miglior consiglio che posso dare: avere uno standard di codifica scritto e accessibile al web (come questo uno ), e richiede che i revisori si attengano scrupolosamente a quest'ultimo quando segnalano i difetti. Molti sviluppatori di software tendono ad avere tendenze OCD (ho il sospetto che sia ciò che ci rende bravi a codificare), e se non si appiattiscono le recensioni di codice, possono diventare un pulpito prepotente per coloro che non sopportano questo:

if (!initialized_) {
    initObject(obj);
}

quindi continuano a provare a influenzare le persone per farlo invece:

if ( ! initialized_ )
{
    initObject( obj );
}

Le distinzioni come questa sono quasi del tutto prive di significato e sono mai un fattore determinante per il successo o il fallimento di un progetto / azienda. Quindi, lasciare il posizionamento del tutore esplicitamente non specificato nello standard, o semplicemente scegliere qualcosa e richiedere a tutti di convivere con esso. Meglio ancora, usa qualcosa come noncrustify in un hook di commit per applicare una sintassi 'standard'. Una società diversa per cui ho lavorato lo ha fatto, e all'epoca pensavo che fosse strano, ma io totalmente lo capisco subito. Qualunque cosa è meglio che avere gli sviluppatori che sprecano soldi discutendo incessantemente sulle banalità. Possiamo farlo durante il pranzo. (E lo faremo comunque. È come uno sport per noi.)

Se hai uno standard pubblicato che "colpisce i punti più alti", penso che lo stesso team di sviluppo possa gestire le revisioni del codice. È così che lo facciamo nel mio attuale lavoro. (Usiamo Crucible , FWIW, e mi piace molto bene.) Il QA non è coinvolto nel processo di revisione in tutti. Uno sviluppatore che vuole unire il suo codice crea semplicemente una recensione e invita altri sviluppatori a unirsi. Ha una luce verde per unire quando tutti hanno terminato la revisione e tutti i difetti sono stati risolti. Non c'è rigida applicazione. Dovresti 'creare una revisione del codice prima di unire il ramo dell'argomento, e quasi tutti lo fanno, ma occasionalmente le circostanze richiedono un'unione' canaglia '. Per il nostro team di 25+ ingegneri, questo ha funzionato abbastanza bene.

Avere una revisione QA del codice prima che entri in produzione è sicuramente una buona pratica ed è raccomandata. La revisione generale del codice da parte di altri sviluppatori di team viene in genere eseguita prima del controllo qualità. Tuttavia, le dimensioni del team, il prodotto specifico, la cultura e così via determinano come deve essere eseguita la revisione del codice. Quello che consiglio è di fare una revisione del codice con più persone che leggono il codice. Inoltre, se si hanno diversi membri del team, suggerirei che diverse persone rivedessero il codice non solo lo sviluppatore principale. I membri del team con meno esperienza potrebbero non essere in grado di identificare tanti problemi, ma impareranno non solo nuovi modi di fare le cose e acquisire familiarità con il codice supportato dal team.

Nel nostro caso, il codice viene spedito quando soddisfa i requisiti specificati. Viene effettuato un accurato processo di verifica, revisione e convalida del software per assicurare che i requisiti siano pienamente soddisfatti.

Sebbene abbiamo linee guida sullo stile informale (e la revisione del codice critico), questa è una considerazione secondaria. Lavoro con un sacco di persone molto intelligenti e la qualità del codice è raramente un problema.

Code review is very effective when contineous and implicit within the team.

Ecco perché non è esplicito nella nostra Definizione di fatto .

Ecco come funziona:

• Le attività non sono assegnate , i membri del team possono decidere di lavorare da soli su qualsiasi attività o partner con un altro sviluppatore.
• Loro comunicano attraverso l'intero processo e si esaminano a vicenda.
• A volte decidono di fare pair programming che è, IMHO, il miglior processo di revisione del codice di sempre.
• La programmazione di coppie garantisce che il codice prodotto non sia posseduto da un individuo e soddisfi le linee guida di codifica del team.

Con questo sistema, è molto improbabile che uno sviluppatore lavori da solo sul suo modulo senza alcun aiuto esterno. Questo comportamento è naturale quando le attività non sono assegnate.

È per questo che è molto importante avere il tuo team situato nello stesso posto, nello stesso ufficio o diviso in due stanze da 3 desk.

Educazione continua (dagli architetti agli sviluppatori ) delle cose e uno spirito di squadra in cui tutti sono responsabili anche del lavoro straniero. Il controllo nel senso della garanzia della qualità è buono ma non sufficiente nella situazione critica del progetto (linee morte). Hai bisogno di cose che lavorino duro per ottenere l'impossibile, tutti insieme.