Diciamo che si lavora in una società ipotetica che ha diversi sviluppatori che raramente hanno lavorato insieme su progetti e il Boss non credeva che le recensioni di codice valessero il tempo e il costo.
Quali sono i vari argomenti che potrebbero essere presentati in questo scenario che ritraggono il vantaggio della revisione del codice? Inoltre, quali sono i potenziali argomenti contro la revisione del codice qui e come possono essere neutralizzati?
Se devi giustificarti per cose di base, hai un problema più grande.
Sei l'esperto, il tuo team dovrebbe decidere quali pratiche utilizzare. Forse dovresti iniziare a convincere il tuo capo di questo principio molto importante.
Your boss is supposed to decide WHAT to do and more importantly WHY doing it. You should take care of the HOW build it
(ciò non significa che non puoi suggerire cosa e perché fare le cose nella tua azienda, ovviamente). Un grande capo dovrebbe incoraggiare i suoi dipendenti a partecipare alla strategia aziendale
Tuttavia, ecco come visualizzo le recensioni dei peer code:
Poiché la programmazione è un lavoro intellettuale molto intenso, una persona non può garantire che tutto sia perfetto. Pertanto la revisione del codice garantisce che:
Tutti ne traggono benefici diretti:
La revisione del codice consente a più sviluppatori di familiarizzare con lo stesso codice. Questa è una buona cosa. Cosa succede se l'autore originale decide di smettere o peggio, gli succede qualcosa di brutto. Se le revisioni del codice vengono eseguite regolarmente, altre possono subentrare rapidamente.
I peer potrebbero essere in grado di individuare potenziali bug o problemi di prestazioni durante la revisione del codice. Ciò riduce il controllo della qualità e lo sforzo di sviluppo. Questo può compensare il costo aggiuntivo implicato nelle revisioni del codice.
Le revisioni del codice promuovono la condivisione delle conoscenze. I pari possono raccontare modi migliori o modi alternativi di fare cose. Io stesso ho imparato molto dai miei colleghi attraverso le recensioni del codice.
Le revisioni del codice aiutano a rafforzare le linee guida sulla codifica seguite dal team. Se la squadra non ne ha uno, è necessario correggerlo. Il codice è pensato per essere scritto una volta e letto molte volte. Le linee guida di codifica sono un passo avanti verso il codice leggibile. Il codice è pensato per essere leggibile dai colleghi. Quale modo migliore di avere recensioni di codice per garantire la leggibilità?
Un sacco di ottime risposte qui. Alcune cose che vorrei aggiungere:
Quando devi spiegare il codice a qualcun altro, spesso nel corso della spiegazione lo sviluppatore può improvvisamente rendersi conto di avere un bug. Ho visto accadere ancora e ancora che il dev si ferma di colpo e dice "oh aspetta che sia sbagliato" prima che il recensore abbia capito la cosa abbastanza bene da vedere il bug.
Sapere che il tuo codice verrà ispezionato da qualcun altro ti darà più incentivi a usare gli standard di codifica (semplificando la manutenzione) o usare meno metodi "da cowboy" che nessuno, tranne te stesso (e talvolta nemmeno te stesso) capirà mai. Non vuoi essere imbarazzato quando mostri il tuo codice a qualcun altro, quindi fai un lavoro migliore su di esso in primo luogo. A causa del fattore imbarazzo, lascia meno il codice commentato con: "Non so perché funzioni, ma non lo scherzo." nella base del codice.
Gli sviluppatori che hanno bisogno di una supervisione o formazione più ampia sono facilmente identificabili. Così sono i veri incompetenti. Prima è possibile trovare e risolvere i problemi di prestazioni, meglio è il team nel suo complesso e maggiore sarà la qualità dell'applicazione. È bello scoprire queste informazioni prima di prendere il nuovo ragazzo che ha bisogno di formazione e assegnarlo alla parte più difficile e più critica della tua applicazione.
A volte si tratta solo di correggere un'errata percezione che salverà facendo lo stesso errore in un sacco di altri luoghi. Ad esempio, abbiamo recentemente esaminato alcuni SQL per report complessi e abbiamo scoperto che molti dei nostri nuovi sviluppatori avevano lo stesso equivoco su dove trovare una specifica informazione nel database (ovviamente il posto che avevano scelto sembrava logico che è un problema di progettazione del database che noi anche bisogno di risolvere) che sarebbe fondamentale per scrivere correttamente tutti i report. Trovando il problema e correggendolo nei primi report che hanno scritto, è stato salvato lo stesso errore nel resto dei report. E qualcosa con cui gli sviluppatori più anziani (che lavorano qui non invecchiando) erano così abituati che non pensavano che fosse necessario spiegarlo. Ci ha anche fatto capire che c'erano altre cose che probabilmente ci servivano per assicurarci che i nuovi sviluppatori fossero sempre aggiornati.
I junior possono imparare dal codice più sofisticato scritto dagli anziani (che tendono a capire meglio il trapping degli errori e i casi limite, ad esempio) e gli anziani possono imparare dalle nuove tecniche usate da juniors a cui non sono ancora stati esposti.
A volte le persone che lavorano su parti diverse ma correlate dell'applicazione realizzano che stanno andando in due direzioni diverse e mutuamente esclusive. Ooops, più facile da risolvere ora.
Non è così facile intrufolarsi in valori codificati che cambieranno nel tempo solo per far funzionare la cosa ora. Questo impedisce molti bug futuri come cose che cambiano all'inizio di ogni anno fiscale.
A volte sono rimasto bloccato su come fare qualcosa e ho imparato una nuova tecnica che era proprio quello che volevo dal codice che esaminava le cose di qualcun altro.
Se hai familiarità con il modo in cui pensano gli altri membri del tuo team (quale revisione del codice ti aiuterà a capire), allora sarà più facile risolvere i problemi in un secondo momento, perché inizierai con la comprensione di come Joe si sarebbe avvicinato quel tipo di problema.
Oltre alla condivisione delle conoscenze menzionata dagli altri, trova esempi di bug che sarebbero stati trovati durante una revisione del codice e misura quanto tempo hanno impiegato per risolvere il problema - questo include il tempo speso per la ricerca del problema e il rilascio della versione con patch come così come il tempo effettivo di correzione del bug.
Prendi questo costo, che richiederà probabilmente meno di un paio di giorni di lavoro, e mettilo in contrasto con il tempo che avresti speso per una revisione del codice e agendo sui risultati.
Questo mostrerà al tuo capo che le recensioni del codice valgono la spesa.
Codice Recensioni Can:
Contro
Se è vero, allora come sempre abbiamo sempre il tempo di fare le cose due o tre volte per lo stesso cliente, ma non abbiamo mai abbastanza tempo per farlo bene la prima volta.
Se hai bisogno di fare riferimento a un documento, non guarderei oltre il stimato "codice completo". In esso, il libro descrive quanti errori vengono rilevati con test unitari vs revisione paritaria. È sbalorditivo. I test unitari, se la memoria mi serve correttamente, catturano solo il ~ 30% di tutti i bug, mentre le recensioni formali tra pari prendono il ~ 70%.
Prendi queste informazioni, mostrale nel libro e fai appello al suo lato finanziario. Ci vuole molto più tempo ed è molto più costoso lasciare passare gli errori piuttosto che catturarli precocemente.
Che ne dici di eseguire una demo (un progetto di tipo "mickey mouse" della durata di una settimana) eseguito in parallelo da due team, uno con la revisione del codice, l'altro no.
Alla fine della settimana, valuta la qualità del lavoro di ogni team, sono abbastanza sicuro che i revisori del codice si presenteranno come migliori.
Da Construx di Steve Mccconnel Il business case per migliori pratiche software e Low Hanging Fruit di Software Development, (LHF) risolve questo problema. Da quest'ultimo "LHF che non verrà contrastato dalla gestione superiore" elenca le ispezioni.
Quando lo presenti, concentrati sull'immagine più grande.
Elenca i vantaggi (codice migliore, meno bug, meno riscritture, ecc.) e cita la revisione del codice come one delle tecniche che consiglieresti.
Lo farei parte di un quadro più ampio del fare arte del software
Siate pronti a fare molto lavoro voi stessi nel promuovere questi principi.
Soprattutto non aspettatevi che la persuasione sia una cosa del tipo "un incontro e fatto".
Dovresti costruire il caso nel tempo con calma e in modo coerente. Quando sei più infastidito da bug che sarebbero stati risolti con tecniche migliori, è spesso il momento peggiore per affrontare il tuo caso in quanto è più probabile che tu sia troppo emotivo e meno razionale. Questo potrebbe sembrare un po 'contro-intuitivo, ma è quello che ho imparato in oltre 30 anni di programmazione. Ovviamente ymmv.
Leggi altre domande sui tag code-reviews programming-practices tips