Cosa contiene una revisione di codice standard?

Nella mia azienda, è una discussione via e-mail su quale funzione è implementata e che tipo di bug è stato risolto inviato da chi scrive il codice. E il revisore, che riceve la posta, esaminerà il codice e discuterà della qualità e di come modificare il codice secondo la sua opinione. Cosa contiene una revisione di codice standard?

Nella mia esperienza, la maggior parte delle revisioni del codice formale si trasforma in controllo dello stile perché è facile. Anche quando fornisci una lista di cose da guardare, è abbastanza facile per gli occhi iniziare a vetrare.

Ho scoperto che la revisione del test unitario offre maggiori vantaggi. La maggior parte degli sviluppatori con cui ho lavorato non sa davvero come testare correttamente le unità, e una volta ottenuto questo "Aha!" momento in cui anche il resto del loro codice inizia a migliorare. Ecco un suggerimento: non è un test unitario se si richiede all'utente di ispezionare qualcosa, e non è un test unitario se si sta semplicemente avviando qualcosa per l'esecuzione in un debugger.

Tende a variare in base al problema. Molte volte è un semplice timbro di gomma. "Ecco qual era il problema, guarda questa riga qui, è ovvio che cosa non va, ed ecco dove l'ho risolto." "Sì, è abbastanza ovvio. Vai avanti e controllalo."

Ma quando succede qualcosa di più coinvolto, di solito va così:

• Esegui Controlla modifiche su TortoiseSVN e ottieni un elenco di file modificati.
• Porta il recensore nel tuo ufficio.
• Spiegare il problema, con il CR del sistema di tracciamento dei bug aperto per riferimento.
• Scorri l'elenco dei file in TortoiseSVN, aprendo ciascuno di essi in BeyondCompare per visualizzare le modifiche.
• Se il revisore non comprende le modifiche, spiega cosa hai fatto e perché.
• Il recensore potrebbe notare qualcosa che non sembra buono. In tal caso, discuterne fino a raggiungere un accordo sull'opportunità o meno di modificarlo. (Se è necessario apportare semplici modifiche, è anche possibile modificare il file all'interno di BeyondCompare.)
• Se hai apportato modifiche, ricompila e assicurati che venga compilato!
• Esegui il programma per dimostrare al revisore che la tua correzione funziona davvero.
• Check in.

IMO, Una revisione del codice non ha nulla a che fare con funzionalità o bug, ma si concentra sulla qualità del codice e sui test scritti per esso.

Quindi, ti siedi accanto al tuo pari e gli fai spiegare il codice, o prendi il codice e lo attraversi, qualunque sia la situazione richiesta.

Aiuta quando tutti programmano contro gli stessi standard e se si utilizzano strumenti come fxCop per automatizzare parte del processo.

Preferisco la revisione del codice in cui lo sviluppatore si trova con il revisore e passa attraverso il codice riga per riga spiegandolo. Spesso, lo sviluppatore vedrà un problema nel fare la spiegazione che il recensore potrebbe non aver ancora visto, motivo per cui questa è la mia preferenza. Faccio anche revisioni del codice in cui mi viene inviato il codice, lo leggo da solo e faccio commenti, ma trovo che tendono a richiedere più tempo (rivedo e redigo i commenti e invio agli sviluppatori che li leggono e vanno WTF vuol dire ed e-mail me lo dico e lo spiego e due o tre round dopo ci riuniamo e sottolineo sullo schermo cosa intendo e lo sviluppatore dice "oh sì, ora lo vedo.") ed essere meno produttivo in quanto c'è una discussione meno genuina e più "Hai fatto questo male".

È anche fondamentale applicare gli standard in una revisione del codice, ma non renderli l'unico obiettivo.

Tuttavia, il codice non viene inviato alla produzione fino a quando il revisore del codice non è soddisfatto o il manager (non lo sviluppatore) lo ha annullato (anche i revisori del codice hanno sbagliato). Questo è fondamentale o la revisione del codice è solo un processo burocratico senza valore aggiunto a meno che il revisore del codice non debba approvare il codice finale prima che venga inviato.

Per prima cosa devi avere standard di codifica e questi sono più che semplici sintassi. Quando le persone iniziano nella tua azienda, devono imparare il più possibile le linee guida della tua azienda prima di iniziare a scrivere codice . Se nel processo di revisione vengono rilevati tutti i tipi di violazioni, molto probabilmente:

• non essere riparato a causa di vincoli temporali
• trovato più fastidioso di quanto valgono le linee guida

Le linee guida dovrebbero avere un senso e dovrebbero esserci strumenti adeguati per trovare le violazioni e refactoring il più semplice possibile. Guarda sempre l'obiettivo delle linee guida e la revisione del codice

L'obiettivo nella mia mente è quello di rendere il codice il più uniforme possibile e trovare problemi di manutenibilità e leggibilità. Un obiettivo secondario può essere quello di far accelerare più persone con un determinato software.

Le linee guida nella mia mente potrebbero ad esempio esistere di:

• sintassi generale e linee guida per la codifica (scegline una già esistente e usa strumenti che controllano automaticamente)
• Corretta gestione delle eccezioni
• Registrazione corretta
• Buon uso dei paradigmi per la lingua (SOLIDO per le lingue OO)
• Dipendenze evidenti e ben ponderate tra i componenti (utilizzare strumenti come NDepend)
• Script di compilazione funzionante
• Documentazione presente (avvio dello sviluppatore, manuale di installazione)
• librerie interne da usare
• politiche aziendali
• strumenti di terze parti non consentiti
• Test unitari presenti e non falliti
• copertura del codice del 90%
• ...

Con questo in atto, la revisione del codice consiste nel controllo del software rispetto alle linee guida e:

• discutere le violazioni con il programmatore
• correggere violazioni non necessarie
• commentare le violazioni necessarie