Le revisioni del codice sono necessarie per gli sviluppatori junior?

Analisi del codice : il processo di revisione del codice deve essere un vitale per tutti, spiegherò chi ottiene tutti i benefici a causa dell'esecuzione della revisione del codice e di cosa sono i vantaggi che stanno ottenendo.

1. Vantaggi ottenuti dalla società a causa della revisione del codice:         Se viene eseguita una frequente revisione del codice, l'azienda può ottenere i prodotti finali in modo molto più ottimizzato che li aiuta a ottenere il nome di marca nel loro mercato e anche aiutare la società a ottenere o migliorare il loro attuale livello CMMI .

2. Vantaggi per il Team Leader dovuto alla conduzione della revisione del codice:        Come tutti sappiamo, un insegnante può facilmente identificare gli errori, perché stanno rivedendo le risposte dei loro studenti più frequentemente, in modo che possano farsi un'idea, in quali aree potrebbero essere possibili cose sbagliate. allo stesso modo il capo squadra sa anche quali sono le cose che vanno storte in queste aree. Come possiamo correggerli. Inoltre, aiuta il team leader a prendere le idee di notizie anche dallo sviluppatore junior.

3. Vantaggi per lo sviluppatore minore dovuto alla revisione del codice:        Junior Developer può facilmente afferrare le idee sul processo di revisione del codice, inoltre sono in grado di ottenere quello che è lo standard di codifica, Per istanza: per creare API in modo corretto, impareranno la standardizzazione della codifica che potrebbe aiutarli in futuro in particolare quando sono diventati nel post di livello più alto.

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

Personalmente ritengo che ogni codice debba passare attraverso una revisione del codice, non importa se sei uno sviluppatore junior o senior.

Perché? Per i principianti il tuo titolo non dice nulla su come ti sviluppi e uno sviluppatore senior potrebbe imparare qualcosa dai giovani. Nella nostra azienda ci spostiamo in modo che uno degli altri membri del team riveda il tuo codice ... per lo più siamo un "junior" e un senior insieme, quindi tutte le cose che non vengono dette ogni giorno possono essere catturato in un seguito. Se al senior non piace il codice junior, dovrebbe ascoltare perché lo junior ha fatto quello che ha fatto e guardarlo e vedere se è una soluzione fattibile che potrebbe essere usata in futuro ... è una questione di diventare più saggi, non importa chi sei.

Una cosa importante della revisione del codice non è troppo bella, se sei un bravo ragazzo ti permetti di far evolvere nel sistema sempre più codice disordinato. Proprio come ieri ho iniziato a rielaborare un'applicazione completa che un ex impiegato di juniordeveloper ha scritto, e il mio dio quel codice avrebbe potuto aver bisogno di una recensione prima che se ne andasse.

Non vedo perché dovrebbe essere il team leader a fare solo delle 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 il codice dovrebbe essere. Non tutte le aziende assumono persone che si preoccupano veramente di quello che fanno, e quelle uova cattive non dovrebbero essere autorizzate a fare revisioni del codice in quanto probabilmente si limitano a scrollare le spalle e dire "OK" al codice errato.

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 l'Open Source può essere di altissima qualità.

EDIT: La ragione è 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à più senso neanche successivamente, rendendo gli errori più costosi da risolvere. Quindi, rendilo comprensibile oggi mentre lo sviluppatore ricorda ancora il codice. Anche il revisore potrebbe vedere errori o omissioni che lo sviluppatore ha mancato.

Sfortunatamente pochissimi vogliono farlo, ma visto da un punto di vista imprenditoriale dovrebbe essere obbligatorio.

Lavoro in un posto in cui la revisione del codice è ora un requisito, ma non era così piccola come 3 anni fa. Ha fatto un enorme miglioramento nel nostro codice e nella capacità degli altri di mantenere il codice in seguito. Anche gli sviluppatori senior di grande esperienza commettono errori che possono essere facilmente e tranquillamente risolti nella revisione del codice prima che il QA li trovi o peggio prima che il cliente li trovi. Inoltre almeno una persona diversa dallo sviluppatore originale ha familiarità con il codice.

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

Ho trovato nuove tecniche che non avevo considerato sia nel fare una revisione del codice del lavoro di qualcun altro sia nel rivedere il mio codice. Abbiamo riscontrato problemi di competenza con i nuovi assunti in tempi relativamente brevi grazie alla revisione del codice e, ancora più importante, al modo in cui hanno risposto alla revisione del codice. Abbiamo appreso quali cose sembrano perfettamente chiare in questo momento nel pieno della programmazione di quella sezione che non sarà chiara nella manutenzione. Questo è inestimabile. Può essere che l'unica cosa necessaria sia un commento sul motivo per cui qualcosa è stato fatto. Abbiamo riscontrato alcuni malintesi fondamentali sulla progettazione del nostro database che dovevano essere corretti perché un report avesse effettivamente le informazioni corrette.

Spesso quello che ho visto in una revisione del codice è che, con l'atto stesso di 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 la revisione del codice del ragazzo può identificare quei programmatori cowboy che non seguiranno alcun standard o utilizzare strumenti obbligatori e il cui codice sarà quasi impossibile da parte di chiunque altro. E può costringerli a ottenere con il programma o uscire anche.

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

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

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

Nel mio attuale team, il codice di Everyones viene esaminato allo stesso modo, e sia il programmatore che il revisore devono essere soddisfatti del codice prima che possa essere rilasciato. Ciò vale tanto per gli sviluppatori senior che vengono esaminati da sviluppatori più giovani, ma anche da uno sviluppatore junior che esamina un altro o altri sviluppatori senior che si rivedono a vicenda. Se il revisore è inesperto o non si sente a suo agio nel rivedere qualsiasi particolare parte di codice, collaborerà con un altro sviluppatore (e forse anche con lo sviluppatore originale) per eseguire la revisione come gruppo.

Lavoro nel settore da oltre 20 anni, lavorando per aziende di software e per diverse attività commerciali e nessuno di questi luoghi ha avuto un processo di revisione del codice. Tuttavia, posso capire e apprezzare i benefici di averne uno. Essenzialmente, come li comprendo, dovrebbero essere utilizzati per garantire l'aderenza agli standard, che dovrebbero essere seguiti affinché altri possano 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. Occasionalmente abbiamo portato degli appaltatori per aiutare con l'arretrato. Almeno uno o due di questi contraenti hanno scritto un codice che non corrisponde necessariamente agli standard della mia o delle compagnie, ma ha funzionato bene ed è stato almeno in qualche modo comprensibile. Quando ho segnalato questo problema alla direzione, a loro non importava, volevano solo sapere se ha fatto ciò che gli abbiamo pagato. Quindi, immagino dipenda solo dalla compagnia, e se il codice sia pulito, facile da mantenere è il prodotto desiderato o se vogliono solo qualcosa che funzioni bene per i soldi.

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

Le revisioni del codice possono identificare i difetti prima nel ciclo di vita del software quando i problemi sono più facili (e meno costosi) da risolvere. SmartBear abbiamo sviluppato uno strumento di revisione del codice peer e abbiamo ha fatto anche molte ricerche su come rendere efficaci le revisioni del codice. Sulla base dei dati dei nostri clienti, i difetti rilevati nella revisione del codice sono 8-12 volte più economici da trovare e risolvere rispetto ai difetti riscontrati nel controllo qualità. Il solo risparmio sui costi fa sì che la revisione del codice ne valga la pena, ma c'è più valore di questo. La revisione del codice è un modo eccellente per tutti i membri del team di apprendere e migliorare come sviluppatori di software.

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

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

A mio parere, il codice che verrà utilizzato da un'azienda, sia che sia stato scritto da uno sviluppatore Junior o Senior, dovrebbe sempre essere rivisto. Perché? Perché e se il codice avesse diversi bug? E se, durante il periodo di utilizzo di questo codice, il programma si arrestasse in modo anomalo? Per evitare che queste cose accadano, tutto il codice dovrebbe essere rivisto prima dell'uso.

Ma che dire di quelle aziende che non esaminano il codice? Sono probabilmente le aziende che hanno molti problemi tecnici e molti, come dicono ai consumatori, "si schiantano" ;-).

Quindi lasciami rispondere a tutte le tue domande:

• Sì, il processo di revisione è necessario.
• Perché? Per le ragioni che ho affermato sopra.

Qual è la differenza con l'interferire con le tue idee prima di controllare il tuo codice (revisione) o successivamente a causa di un bug, diventando troppo intelligente / difficile da capire o non seguendo le pratiche standard accettate? È il tuo ego?

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

Sei mai tornato su una linea di codice qualche mese dopo e ti sei chiesto cosa stavo pensando? Ci sarebbe una migliore possibilità di vederlo con una revisione del codice. L'hai appena catturato e sei solo leggermente migliore del programmatore che eri da un po 'di tempo - spero.

IMO una revisione del codice dovrebbe essere essenziale per tutti gli sviluppatori, ma solo quando le persone che fanno la revisione sono competenti. In passato ho avuto il codice rifiutato in una recensione perché, non scherzo, ho seguito SOLID , ho fatto un po 'di Dependency Injection e ho organizzato il codice in spazi dei nomi e cartelle secondo il progetto logico, e ho incluso una piccola suite di test unitari per verificare il codice. Il codice è stato rifiutato come "troppo complicato" e mi è stato detto di utilizzare una classe che annusasse tutto 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 es. Perché dovresti fare X e Y ma non Z) o indicare un difetto reale (ad es. Doing X causerà Y fallire per motivi errati).

Ovviamente Code Review non è necessario . Inoltre, non ci sono test, integrazione continua, controllo del codice sorgente, coinvolgimento del cliente, profilazione, analisi statica, hardware decente, build con un clic, tracciamento dei bug, la lista continua.

Insieme alle recensioni dei codici, le cose che ho menzionato sopra sono strumenti che aiutano a garantire la qualità del software. Con una combinazione di abilità, fortuna, tempo e determinazione; puoi fornire software di qualità senza alcuna di queste cose, ma è più probabile che non .

Nel tuo scenario, non c'è nulla di cui essere confusi. Non tutte le organizzazioni si dedicano a tutte le migliori pratiche. Potrebbero non essere d'accordo con esso, potrebbe entrare in conflitto con una best practice diversa che implementano, oppure potrebbero ritenere che il sovraccarico di implementazione sia troppo grande per loro in questo momento. A seconda delle circostanze, potrebbero essere corretti nel farlo, oppure potrebbero fare una falsa economia. Per alcuni strumenti (ad es. Il controllo del codice sorgente) il rapporto ritorno / sforzo è così buono che usarlo è 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 minimizzare il sovraccarico, o non facendolo affatto, o solo facendolo in certe situazioni (ad es. Per un membro del team junior o un cambiamento particolarmente peloso). Non è sempre ovvio che ripaga di più (nel catturare bug, ridurre il debito tecnico o condividere conoscenze) di quanto costi. La maggior parte di questo recupero è difficile da quantificare, mentre è molto facile contare il numero di ore uomo in cui la tua organizzazione spende le revisioni. Il bit più semplice da quantificare (conteggio degli errori ridotto) è facile da attribuire ad altri fattori (ad esempio "naturalmente ha meno bug, è più maturo").

Realizziamo partite di calcio online in Turchia. Un sacco di utenti e maestri del gioco ci aiutano sulla funzionalità. Inoltre danno commenti sulle funzionalità necessarie. Quindi penso che, se si hanno molti utenti, è possibile eseguire test di funzionalità per aiutare o ottenere badge. Collobration di sviluppatori, maestri di giochi e utenti con forum, team di supporto e ambienti di test privati creano un progetto sociale.

È necessaria la revisione sicura del codice e la condivisione delle esperienze tra il team di sviluppo, ma se non è fondamentale non devi forzarti.

Penso che la verbosa ispezione della seconda parte dipenda dal tuo ciclo di vita, dal fatto che tu sia più agile o più coinvolgente nei tuoi processi. Penso che sia ragionevole fare disegni / ispezioni di alto livello, così come più ispezioni di progettazione del livello di dettaglio. Penso che sia anche utile coinvolgere diversi membri di una squadra per l'ispezione.

Sono assolutamente necessari poiché hanno poca esperienza.