Che cosa contiene una revisione del codice standard?

Nella mia esperienza, la maggior parte delle revisioni di codice formali si basano sul controllo dello stile perché è semplice. Anche quando fornisci una lista di cose da guardare, è piuttosto facile per gli occhi iniziare a glassare.

Ho trovato che la revisione del test unitario offre più benefici. La maggior parte degli sviluppatori con cui ho lavorato non sa veramente come eseguire il test unitario e una volta ottenuto "Aha!" momento il resto del loro codice inizia a migliorare pure. Ecco un suggerimento: non si tratta di un test unitario se si richiede all'utente di ispezionare qualcosa, e non si tratta di un test unitario se si sta appena iniziando qualcosa da eseguire in un debugger.

Tende a variare in base a quale sia il problema. Un sacco di volte è un semplice timbro di gomma. "Ecco qual è il problema, guarda qui questa linea, è ovvio che cosa sta andando male, ed ecco dove l'ho risolto". "Sì, è abbastanza ovvio. Vai avanti e controlla."

Ma quando succede qualcosa di più impegnativo, di solito è così:

• Esegui il controllo delle modifiche su TortoiseSVN e ottieni un elenco dei file modificati.
• Porta il revisore nel tuo ufficio.
• Spiega il problema, con il CR dal sistema di tracciamento dei bug aperto come riferimento.
• Vai giù nell'elenco di file in TortoiseSVN, aprendo ognuno di essi in BeyondCompare per visualizzare le modifiche.
• Se il revisore non comprende le modifiche, spiega cosa hai fatto e perché.
• Il revisore potrebbe notare qualcosa che non ha un bell'aspetto. In tal caso, discuterne fino a quando non raggiungi un accordo sull'opportunità o meno di modificarlo. (Se è necessario apportare semplici modifiche, puoi persino modificare il file all'interno di BeyondCompare.)
• Se hai apportato modifiche, ricompilalo e assicurati che si sviluppi!
• Esegui il programma per dimostrare al revisore che la tua correzione funziona davvero.
• Controllalo.

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

Quindi, ti siedi accanto al tuo pari e fagli spiegare il codice, o prendi il codice e fallo passare, qualunque sia la situazione.

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

Preferisco la revisione del codice in cui lo sviluppatore si trova con il revisore e passa il codice riga per riga spiegandolo. Spesso, lo sviluppatore vedrà un problema nel fare la spiegazione che il revisore potrebbe non aver ancora visto e questo è il motivo per cui questa è la mia preferenza. Eseguo anche le revisioni del codice in cui mi viene inviato il codice e letto da solo e faccio commenti, ma trovo che tendono a richiedere più tempo (riesaminare e scrivere commenti e inviare a dev chi li legge e fa WTF significa e email me indietro e spiego e due o tre giri dopo ci riuniamo e faccio notare sullo schermo cosa intendo e lo sviluppatore dice "oh sì, ora lo vedo".) ed essere meno produttivo in quanto vi è una discussione meno genuina e di più: "Hai sbagliato".

È 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 è felice o il gestore (non lo sviluppatore) ha annullato la sua scelta (anche i revisori del codice hanno sbagliato). Questo è un aspetto critico o la revisione del codice è solo un processo burocratico senza valore aggiunto a meno che il revisore del codice non approvi il codice finale prima di essere inviato.

Per prima cosa è necessario disporre di 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 la codifica . Se nel processo di revisione vengono rilevati tutti i tipi di violazione, molto probabilmente saranno:

• non può essere corretto a causa dei limiti di tempo
• si è rivelato più fastidioso di quanto valgano le linee guida

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

The goal in my mind is to make the code as uniform as possible and to find issues with maintainability and readability. A secondary goal can be to get more people up to speed with a certain piece of software.

Le linee guida nella mia mente potrebbero ad es. esiste di:

• linee guida generali sulla sintassi e sulla codifica (scegli una che esiste già e usa gli strumenti che controllano automaticamente)
• Gestione delle eccezioni corretta
• Registrazione corretta
• Buon uso dei paradigmi per il linguaggio (SOLID per le lingue OO)
• Dipendenze evidenti e ben ponderate tra i componenti (utilizzare strumenti come NDepend)
• Script di build di lavoro
• Presenza della documentazione (avvio dello sviluppatore, manuale di installazione)
• librerie interne da utilizzare
• norme aziendali
• strumenti di terze parti non consentiti
• Test unitari presenti e non in errore
• copertura del codice del 90%
• ...

Con ciò, la revisione del codice consiste nel controllo del software rispetto alle linee guida e:

• discutere le violazioni con il programmatore
• correggi le violazioni inutili
• commentare le violazioni necessarie