Diciamo che uno lavora in un'ipotetica società che ha diversi sviluppatori che raramente hanno lavorato insieme su progetti e il Boss non credeva che le revisioni del codice valessero il tempo e il costo.
Quali sono i vari argomenti che potrebbero essere presentati in questo scenario che illustreranno i vantaggi della revisione del codice? Inoltre, quali sono i potenziali argomenti contro la revisione del codice qui e come possono essere contrastati?
Risposte:
Se devi giustificarti per queste cose basilari, 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 quel principio molto importante.
Il tuo capo dovrebbe decidere COSA fare e, soprattutto, PERCHÉ farlo. Dovresti occuparti del COME costruirlo
(ciò non significa che non puoi suggerire cosa e perché 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 codici peer:
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 può acquisire più sviluppatori con lo stesso codice. Questa è una buona cosa. Che cosa succede se l'autore originale decide di smettere o peggio, succede qualcosa di brutto a lui. 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 QA e lo sforzo di sviluppo. Questo può compensare il costo aggiuntivo coinvolto nelle revisioni del codice.
Le revisioni del codice promuovono la condivisione delle conoscenze. I coetanei possono parlare di modi migliori o modi alternativi di fare cose. Io stesso ho imparato molto dai miei colleghi attraverso le revisioni del codice.
Le revisioni del codice aiutano a rafforzare le linee guida sulla codifica seguite dal team. Se il team non ne ha uno, è necessario correggerlo. Il codice deve essere scritto una volta e letto più volte. Le linee guida per la codifica sono un passo verso un codice leggibile. Il codice deve essere leggibile dai colleghi. Quale modo migliore di avere revisioni del codice per garantire la leggibilità?
Molte grandi risposte qui. Alcune cose che aggiungerei:
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 succedere ancora e ancora che lo sviluppatore si ferma nelle sue tracce e dice "oh aspetta che sia sbagliato" prima che il recensore abbia capito abbastanza bene la cosa per vedere il bug.
Sapere che il tuo codice sarà ispezionato da qualcun altro ti dà più incentivi a usare gli standard di codifica (semplificando la manutenzione) o usando meno metodi "da cowboy" che nessuno tranne te stesso (e talvolta nemmeno te stesso) potrà mai capire. 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 del codice commentato con: "Non so perché questo funzioni, ma non si scherza." nella base di codice.
Gli sviluppatori che hanno bisogno di una supervisione o formazione più ampia sono facilmente identificabili. Così sono i veri incompetenti. Prima riuscirai a trovare e ad affrontare i problemi di prestazioni, migliore sarà il team nel suo insieme e maggiore sarà la qualità dell'applicazione. È utile scoprire queste informazioni prima di assumere il nuovo ragazzo che ha bisogno di formazione e assegnarlo alla parte più difficile e critica dell'applicazione.
A volte si tratta solo di correggere una percezione errata che salverà facendo lo stesso errore in un sacco di altri posti. Ad esempio, di recente abbiamo esaminato alcuni SQL per rapporti complessi e abbiamo scoperto che diversi dei nostri nuovi sviluppatori avevano lo stesso malinteso su dove trovare una specifica informazione nel database (è vero che il luogo che avevano scelto sembrava logico che è un problema di progettazione del database che abbiamo anche bisogno di risolvere) che sarebbe fondamentale per scrivere correttamente tutti i rapporti. Individuando il problema e correggendolo nei primi rapporti scritti, è stato salvato lo stesso errore nel resto dei rapporti. E qualcosa a cui gli sviluppatori più anziani (nel tempo lavorano qui non in età) erano così abituati da non pensare che fosse necessario spiegarli.
I giovani possono imparare dal codice più sofisticato scritto dagli anziani (che tendono a comprendere meglio il trapping degli errori e i casi limite per esempio) e gli anziani possono imparare dalle nuove tecniche utilizzate dai giovani a cui non sono ancora stati esposti.
A volte le persone che lavorano su parti dell'applicazione diverse ma correlate si rendono conto che stanno andando in due direzioni diverse e reciprocamente esclusive. Ops, più facile da risolvere ora.
Non è così facile intrufolarsi in valori codificati che cambieranno nel tempo solo per far funzionare la cosa ora. Ciò impedisce molti bug futuri come cose che cambiano all'inizio di ogni anno fiscale.
A volte sono stato bloccato su come fare qualcosa e ho imparato una nuova tecnica che era proprio quello che volevo da rivedere il codice di qualcun altro.
Se hai familiarità con il modo in cui gli altri membri del tuo team pensano (quale revisione del codice ti aiuterà a capire), allora sarà più facile risolvere i problemi in seguito perché inizierai con una comprensione di come Joe avrebbe affrontato quel tipo di problema.
Oltre alla condivisione delle conoscenze menzionata dagli altri, trova esempi di bug che sarebbero stati rilevati durante una revisione del codice e misura il tempo impiegato per risolvere il problema, incluso il tempo dedicato alla ricerca del problema e al rilascio della versione con patch, nonché al tempo effettivo di correzione del bug.
Prendi questo costo, che probabilmente sarà uno sforzo di almeno un paio di giorni, e confrontalo con il tempo che avresti speso per una revisione del codice e agire sui risultati.
Questo mostrerà al tuo capo che le revisioni del codice valgono la spesa.
Le recensioni dei codici possono:
Contro
Se è vero, allora come mai sembriamo sempre di avere 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 cercare oltre il stimato "Codice completo". In esso, il libro descrive quanti errori vengono rilevati con i test unitari e la revisione tra pari. È sorprendente. I test unitari, se la memoria mi serve bene, catturano solo il 30% di tutti i bug mentre le revisioni formali tra pari catturano il 70% circa.
Prendi queste informazioni, mostralo nel libro e fai appello al suo lato finanziario. Ci vuole molto più tempo ed è molto più costoso per consentire ai bug di superarli piuttosto che catturarli in anticipo.
Che ne dici di eseguire una demo (un progetto tipo "topolino" di una settimana) eseguito in parallelo da due team, uno usando la revisione del codice, l'altro no.
Alla fine della settimana, valuta la qualità del lavoro di ogni squadra, sono abbastanza sicuro che i revisori del codice verranno meglio.
Da Construx di Steve Mcconnel The Business Case for Better Software Practices and Software Development's Low Hanging Fruit (LHF) affronta questo problema. Da quest'ultimo "LHF che non sarà resistito dalla direzione superiore" elenca le ispezioni.
Quando lo presenti, concentrati sull'immagine più grande.
Elenca i vantaggi (codice migliore, meno bug, meno riscritture, ecc.) E menziona la revisione del codice come una delle tecniche che consiglieresti.
Vorrei renderlo parte di un quadro più ampio del fare arte del software
Preparati a fare molto lavoro te stesso nel promuovere questi principi.
La maggior parte di tutti non si aspetta che la persuasione sia una cosa "un incontro e fatto".
Dovresti costruire il caso nel tempo con calma e coerenza. Quando sei più infastidito da bug che sarebbero stati corretti da tecniche migliori, è spesso il momento peggiore per presentare il tuo caso in quanto è più probabile che tu sia troppo emotivo e meno razionale. Questo potrebbe sembrare un po 'controintuito, ma è quello che ho imparato in 30 anni di programmazione. Ovviamente ymmv.