Le revisioni del codice sono necessarie per gli sviluppatori junior?

Ho lavorato in due società, ognuna con una metodologia diversa per quanto riguarda le revisioni del codice:

Nella prima azienda, i leader del team hanno condotto una revisione del codice ed è stato richiesto dopo il completamento di ogni modulo.

Tuttavia, nella seconda società, i leader del team non erano tenuti a condurre alcuna revisione del codice e hanno semplicemente verificato la presenza di problemi di funzionalità e design.

Quindi sono confuso. Il processo di revisione del codice è davvero necessario? Se lo è, perché? E se non lo è, perché no?

Personalmente penso che ogni parte di codice dovrebbe passare attraverso una revisione del codice, non importa se sei uno sviluppatore junior o senior.

Perché? Tanto per cominciare il tuo titolo non indica nulla su come sviluppi, e uno sviluppatore senior potrebbe imparare qualcosa dai junior. Nella nostra azienda ci spostiamo in modo che uno degli altri membri del team riveda il tuo codice ... per lo più siamo uniti da un "junior" e un senior insieme, quindi tutto ciò che non viene detto su base giornaliera può essere preso in un seguito. Se al senior non piace il codice junior, dovrebbe ascoltare il motivo per cui il junior ha fatto quello che ha fatto e guardarlo e vedere se questa è una soluzione fattibile che potrebbe essere utilizzata in futuro ... è una questione di diventare più saggi, non importa chi sei.

Una cosa importante della revisione del codice non è essere troppo carino, se sei un bravo ragazzo, consentirai solo ad un codice sempre più disordinato di evolversi nel sistema. Proprio come ieri ho iniziato a rielaborare un'applicazione completa scritta da un ex juniordeveloper impiegato, e mio dio quel codice avrebbe potuto aver bisogno di una revisione prima di partire.

Non vedo perché dovrebbe essere il teamleader a fare solo recensioni ma richiede una persona che non ha paura di scegliere una "lotta" su un pezzo di codice mal sviluppato, e deve essere una persona che si preoccupa di come dovrebbe essere il codice essere. Non tutte le aziende assumono persone che si preoccupano realmente di ciò che fanno, e a quelle uova cattive non dovrebbe essere permesso a IMO di fare recensioni di codice in quanto è probabile che si limitino a scrollare le spalle e dire "OK" a codice cattivo.

Fondamentalmente la revisione del codice è necessaria per tutti i programmatori indipendentemente dall'esperienza. È il controllo di qualità dello sviluppo del software e uno dei motivi per cui Open Source può essere di altissima qualità.

EDIT: il motivo è che un revisore del codice oggi ha esattamente lo stesso ruolo di un manutentore in seguito. Se il codice non ha senso per lui oggi, non avrà nemmeno senso in seguito, rendendo i bug più costosi da correggere. Quindi, RENDI comprensibile oggi mentre lo sviluppatore ricorda ancora il codice. Inoltre, il revisore può vedere bug o omissioni che lo sviluppatore ha perso.

Sfortunatamente pochissimi vogliono farlo, ma visto dal punto di vista commerciale dovrebbe essere obbligatorio.

Lavoro in un luogo in cui la revisione del codice è ora un requisito, ma non meno di 3 anni fa. Ha apportato un enorme miglioramento al nostro codice e alla capacità di altri di mantenerlo in seguito. Anche gli sviluppatori senior e di grande esperienza commettono errori che possono essere facilmente e tranquillamente risolti nella revisione del codice prima che il QA li trovi o peggio ancora prima che il cliente li trovi. Inoltre almeno una persona diversa dallo sviluppatore originale ha familiarità con il codice.

Spesso quando un'organizzazione prova qualcosa di nuovo, come abbiamo fatto con la revisione del codice, c'è molta resistenza al cambiamento. Non ho visto quasi nulla di tutto ciò (eravamo estatici anche per ottenere un dipartimento formale di controllo qualità) con la revisione del codice. Praticamente ci vogliono solo una o due recensioni per vedere il valore.

Ho trovato nuove tecniche che non avevo preso in considerazione sia nel fare una revisione del codice del lavoro di qualcun altro, sia nel fare rivedere il mio codice. Abbiamo riscontrato problemi di competenza con i nuovi assunti relativamente rapidamente avendo recensioni di codice e, soprattutto, da come hanno risposto alla revisione del codice. Abbiamo imparato quali cose sembrano perfettamente chiare in questo momento nel bel mezzo della programmazione di quella sezione che non sarà chiara nella manutenzione. Questo è prezioso. Può darsi che l'unica cosa necessaria sia un commento sul perché qualcosa è stato fatto. Abbiamo riscontrato alcuni fraintendimenti fondamentali sulla progettazione del nostro database che dovevano essere corretti affinché un report avesse effettivamente le informazioni corrette.

Spesso ciò che ho visto in una revisione del codice è che, proprio per spiegare qualcosa a qualcun altro, lo sviluppatore avrà una lampadina accesa nella sua testa e si renderà conto che c'è un bug che il revisore non ha visto.

E il ragazzo può ripassare il codice identificando quei programmatori di cowboy che non seguiranno nessuno standard o useranno strumenti obbligatori e il cui codice sarà pressoché irrintracciabile da chiunque altro. E può costringerli a uscire con il programma o anche uscire.

Le persone più resistenti alla revisione del codice sono spesso le persone di cui l'organizzazione ha più bisogno per sbarazzarsi perché sanno nel loro cuore che il loro codice non può passare una revisione del codice.

Un ragazzo agile direbbe: "Non hai bisogno di una revisione del codice, basta accoppiare la programmazione e scrivere buoni test" :)

La revisione del codice è un buon modo per diffondere conoscenza e buone pratiche attraverso un team. Nella mia esperienza è una buona idea assicurarsi che tutto il codice venga esaminato e provare a variare chi rivede quale codice.

Nel mio attuale team il codice di tutti viene esaminato in modo equo e sia il programmatore che il revisore devono essere soddisfatti del codice prima che possa essere rilasciato. Questo vale tanto per gli sviluppatori senior che vengono esaminati da più sviluppatori junior, uno sviluppatore junior che ne esamina un altro, o che altri sviluppatori senior si esaminano a vicenda. Se il revisore è inesperto o non si sente a proprio agio nel rivedere un particolare pezzo di codice, si unirà a un altro sviluppatore (e forse anche allo sviluppatore originale) per fare la revisione come gruppo.

Sono stato nel settore per più di 20 anni, lavorando per aziende di software e per diverse aziende e nessuno di questi posti ha avuto un processo di revisione del codice. Tuttavia, posso capire e apprezzare i vantaggi di averne uno. Essenzialmente, per quanto li capisco, dovrebbero essere usati per garantire l'adesione agli standard, che dovrebbero essere seguiti per consentire ad altri di mantenere più facilmente il codice in futuro. La leggibilità del codice potrebbe anche essere verificata in un processo di revisione poiché anche questo garantirà che la manutenzione possa funzionare efficacemente con il codice.

Attualmente lavoro in un piccolo negozio in cui sono il singolo sviluppatore. Di tanto in tanto abbiamo portato appaltatori per aiutare con l'arretrato. Almeno uno o due di quei contraenti hanno un codice scritto che non soddisfa necessariamente i miei o gli standard delle aziende, ma ha funzionato bene ed era almeno in qualche modo comprensibile. Quando ho segnalato questo problema alla direzione, a loro non importava, volevano solo sapere se faceva quello che li pagavamo. Quindi, immagino che dipenda solo dall'azienda, e se il codice desiderato sia facile da pulire o meno sia il prodotto desiderato o se vogliono semplicemente qualcosa che funzioni bene per i soldi.

Ovviamente come sviluppatore e uno che deve mantenere il codice, mi piacerebbe lavorare con un codice pulito che segue uno standard di qualche tipo, ma non ho sempre quel lusso, quindi ne approfitto e mi occupo di ciò che ho , anche se a volte significa dover riscrivere un codice nel mio standard.

Le revisioni del codice possono identificare i difetti in precedenza nel ciclo di vita del software quando i problemi sono più facili (ed economici) da risolvere. In SmartBear abbiamo sviluppato uno strumento di revisione del codice peer e abbiamo anche fatto molte ricerche su come rendere efficaci le revisioni del codice. Sulla base dei dati dei nostri clienti, i difetti riscontrati nella revisione del codice sono 8-12X più economici da trovare e correggere rispetto ai difetti riscontrati nel QA. Il solo risparmio sui costi vale la pena rivedere il codice, ma c'è più valore di questo. La revisione del codice è un modo eccellente per tutti i membri del team di imparare e migliorare come sviluppatori di software.

Esistono alcune trappole che possono rendere le revisioni del codice meno efficaci e sembra che la tua organizzazione sia coinvolta in una di esse. Fai la revisione del codice sul codice, non sulle persone. I titoli non significano nulla in una recensione di codice. Gli appelli all'autorità (devi farlo a modo mio perché sono il capo della squadra) fanno più male che bene. Insegna invece. Gli ingegneri senior dovrebbero spiegare perché dovrebbe essere fatto a modo loro, non solo chiederlo. Se hai difficoltà a spiegare un concetto, è un'esperienza di apprendimento anche per te. Entrambi sarete sviluppatori migliori per l'impegno profuso.

Penso che la revisione del codice ALL CODE sia eccessiva. Il tempo necessario per rivedere tutto il codice potrebbe essere speso meglio altrove. Alterntivley Penso che il codice critico e / o pezzi particolarmente complessi necessitino di una revisione del codice, ma certamente non tutte le righe di codice.

A mio avviso, il codice che verrà utilizzato da un'azienda, sia esso scritto da uno sviluppatore Junior o Senior, dovrebbe sempre essere rivisto. Perché? Perché se il codice avesse diversi bug? E se, durante l'utilizzo di questo codice, il programma si fosse bloccato? Per impedire che ciò accada, è necessario rivedere tutto il codice prima dell'uso.

Ma che dire di quelle aziende che non revisionano il codice? Probabilmente sono le aziende che hanno molti problemi tecnici e molti, come dicono ai consumatori, "crash" ;-).

Quindi lasciami rispondere a tutte le tue domande:

• Sì, il processo di revisione è necessario.
• Perché? Per i motivi che ho indicato sopra.

Revisione del codice : il processo di revisione del codice deve essere vitale per tutti, spiegherò chi ha tutti i benefici grazie alla conduzione della revisione del codice e quali sono i vantaggi che stanno ottenendo.

1. Vantaggi ottenuti dalla società grazie alla conduzione della revisione del codice: se viene condotta una revisione frequente del codice, la società può ottenere i prodotti finali in un modo molto più ottimizzato che li aiuta a ottenere il marchio sul loro mercato e anche aiutare la società a ottenere o migliorare il loro attuale livello CMMI .

2. Vantaggi per il team leader grazie alla conduzione della revisione del codice: come tutti sappiamo, un insegnante può identificare facilmente gli errori, perché sta rivedendo le risposte dei propri studenti più frequentemente, in modo che possano farsi un'idea, in quali aree possono essere possibile per cose sbagliate. allo stesso modo il caposquadra sa anche quali sono le cose che vanno male in queste aree. Come possiamo correggere quelli e anche aiutare il team leader a prendere le idee di notizie anche dallo sviluppatore junior.

3. Vantaggi per lo sviluppatore junior grazie alla conduzione della revisione del codice: lo sviluppatore junior può facilmente afferrare le idee sul processo di revisione del codice, inoltre sono in grado di ottenere quello che è lo standard di codifica, ad esempio: creare API in modo corretto, impareranno la standardizzazione della codifica che potrebbe aiutarli in futuro specialmente quando saranno inseriti in post di livello superiore.

Quindi la mia conclusione è che la revisione del codice è un processo molto molto vitale per tutti [anche per i membri del team], poiché la revisione del codice ci aiuta a correggere i nostri errori negligenti nel nostro codice, perché siamo tutti esseri umani, quindi non possiamo prevedere che mai fare errori negligenti nel codice.

Qual è la differenza nell'interferire con le tue idee prima di controllare il tuo codice (recensione) o in seguito a causa di un bug, diventare troppo intelligente / difficile da capire o non seguire le pratiche standard accettate? È il tuo ego?

Non puoi ignorare i meriti della revisione del codice o qualsiasi altra cosa solo perché viene implementata male da un membro del team meno qualificato che non rispetti. La revisione del codice non è un processo estremamente complesso che solo pochi super programmatori sono in grado di comprendere. Non sono sicuro che ci siano molti programmatori o scrittori professionisti che sono in grado o hanno il tempo di auto-modificarsi.

Sei mai tornato a una riga di codice qualche mese dopo e ti sei chiesto cosa stavo pensando? Ci sarebbero maggiori possibilità di prenderlo con una revisione del codice. L'hai appena preso e sei solo leggermente migliore del programmatore che eri un po 'di tempo fa - spero.

Una revisione del codice IMO dovrebbe essere essenziale per tutti gli sviluppatori, ma solo quando le persone che effettuano la revisione sono competenti. In passato ho avuto il codice rifiutato in una recensione perché, non ho scherzato, ho seguito SOLIDun'iniezione di dipendenza e il codice è stato organizzato in spazi dei nomi e cartelle in base al progetto logico, e includeva una piccola suite di unit test per verifica il codice. Il codice è stato respinto come "troppo complicato" e mi è stato detto di usare una classe che ha fatto sparire tutto insieme e rimuovere i test perché non era come la società ha scritto il codice.

Una revisione del codice del genere è inutile, ma una revisione del codice con un team competente può spesso illuminare qualcosa sul design (ad esempio perché dovresti fare X e Y ma non Z) o indicare un difetto reale (ad esempio fare X farà fallire Y per motivi errati).

Naturalmente la revisione del codice non è necessaria . Inoltre, né i test, l'integrazione continua, il controllo del codice sorgente, il coinvolgimento del cliente, la profilazione, l'analisi statica, l'hardware decente, le build con un clic, il monitoraggio dei bug, l'elenco continua.

Insieme alle recensioni di codice, le cose che menziono sopra sono strumenti che aiutano a garantire la qualità del software. Con una combinazione di abilità, fortuna, tempo e determinazione; si può fornire software di qualità, senza nessuna di queste cose, ma è più probabile che non lo faranno .

Nel tuo scenario, non c'è nulla di cui essere confusi. Non tutte le organizzazioni si abbandonano a tutte le migliori pratiche. Potrebbero essere in disaccordo con esso, potrebbe essere in conflitto con una diversa migliore pratica che implementano o potrebbero considerare che il sovraccarico di implementarlo è troppo grande per loro in questo momento. A seconda delle circostanze, potrebbero essere corretti nel farlo, oppure potrebbero creare una falsa economia. Per alcuni strumenti (ad es. Controllo del codice sorgente) il rapporto di ammortamento / sforzo è così buono che utilizzarlo è un gioco da ragazzi; per altri è meno chiaro.

Non c'è dubbio che la revisione del codice sia una pratica che introduce un sovraccarico significativo. Per questo motivo, le organizzazioni cercheranno di ridurre al minimo tale sovraccarico, non facendolo affatto, o facendolo solo in determinate situazioni (ad esempio per un membro del team junior o un cambiamento particolarmente peloso). Non è sempre ovvio che ripaga di più (nella cattura di bug, nella riduzione del debito tecnico o nella condivisione delle conoscenze) di quanto costi. La maggior parte di tale ammortamento è difficile da quantificare, mentre è molto facile contare il numero di ore-uomo che la tua azienda impiega a fare recensioni. Il bit più semplice da quantificare (conteggio dei bug ridotto) è facile da attribuire ad altri fattori (ad es. "Ovviamente ha meno bug, è più maturo").

Realizziamo partite di calcio online in Turchia. Molti utenti e maestri di gioco ci aiutano in termini di funzionalità. Inoltre forniscono commenti sulle funzionalità necessarie. Quindi penso che se hai molti utenti, è possibile eseguire test di funzionalità per aiutare o ottenere badge. Il colloquio di sviluppatori, maestri di gioco e utenti con forum, team di supporto e ambienti di test privati ​​crea un progetto sociale.

Sono necessarie revisioni del codice e condivisione delle esperienze tra il team di sviluppo, ma se non è fondamentale non devi forzare te stesso.

Penso che quanto sia approfondita l'ispezione di seconda parte dipende dal tuo ciclo di vita, se sei più agile o più a cascata nei tuoi processi. Penso che sia ragionevole eseguire ispezioni / progettazioni di alto livello, nonché ispezioni di progettazione più dettagliate. Penso che sia anche bello coinvolgere diversi membri di una squadra per ispezionare.

Sono assolutamente necessari poiché hanno poca esperienza.