Domanda

Ho lavorato in due aziende, che ognuno aveva una metodologia diversa quando si trattava di revisioni del codice:

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

Tuttavia, nella seconda società, team leader non erano tenuti a condurre le revisioni del codice, e solo controllato per problemi di funzionalità e design.

Così mi sono confuso. È il processo di revisione del codice davvero bisogno? Se lo è, perché? E se non lo è, perché no?

È stato utile?

Soluzione 10

Code Review : il processo Code Review deve essere un vitale uno per tutti, spiegherò che sono tutti i benefici get dovuto alla conduzione di revisione del codice così come quello sono i benefici che stanno ottenendo.

1. Vantaggi ottenuti dalla società A causa della conduzione di Code Review: Se la revisione del codice frequente è condotta, allora l'azienda può ottenere i prodotti finali in modo molto migliore ottimizzato che li aiutano a ottenere il nome di marca nel loro mercato e anche aiuto azienda per ottenere o migliorare la loro attuale CMMI Livello.

2. Vantaggi per i Team Leader A causa della conduzione di Code Review: Come tutti sappiamo un insegnante può facilmente identificare gli errori, perché stanno rivedendo le risposte dei loro studenti più spesso, in modo che possano avere un'idea, in quali aree ci possono essere possibile per le cose sbagliate. allo stesso modo il capo della squadra sa anche quali sono le cose va male in queste aree. Come possiamo rimediare those.And Aiuta anche il capo della squadra per afferrare le idee di notizie da parte dello sviluppatore juniores troppo.

3. Vantaggi per il Junior Developer A causa della conduzione di Code Review: Sviluppatore Junior può facilmente afferrare le idee su Code Review Process, anche loro sono in grado di ottenere ciò che è lo standard di codifica, per esempio: per creare API in modo corretto, impareranno la standardizzazione della codifica che li può aiutare in futuro appositamente quando sono in post diventano di livello superiore.

Quindi, la mia conclusione è Code Review è un processo molto molto importante per tutti [anche per squadra Membro troppo], dal momento che il codice Revisione ci aiuta a correggere i nostri errori di distrazione nel nostro codice, perché siamo tutti esseri umani, in modo da non possiamo prevedere che non abbiamo mai fare errori di distrazione nel codice.

Altri suggerimenti

Personalmente ritengo che ogni pezzo di codice deve passare attraverso una revisione del codice, non importa se si è sviluppatori junior o senior.

Perché? Per cominciare il titolo non fa nulla dello stato di come si sviluppa, e uno sviluppatore senior potrebbe imparare qualcosa dalla juniores. Presso la nostra azienda ci spostiamo in giro così uno degli altri membri del team di revisione il codice ... soprattutto stiamo collaborato un "junior" e un insieme di alto livello, in modo da tutte le cose che non viene detto su una base quotidiana può essere catturati in un follow-up. Se l'anziano non piace il codice juniores si dovrebbe ascoltare il motivo per cui la junior fece come ha fatto e un'occhiata e vedere se questa è una soluzione fattibile che potrebbe essere utilizzato in futuro ... è una questione di ottenere più saggio non importa chi sei.

Una cosa importante circa la revisione del codice non è essere troppo bello, se lei è un bel ragazzo ti basta consentire codice sempre più disordinato di evolvere nel sistema. Proprio come ieri ho iniziato a rielaborare una completa applicazione che un ex impiegato juniordeveloper ha scritto, e il mio dio che il codice avrebbe avuto bisogno di una revisione prima di andarsene.

non vedo perché dovrebbe essere il teamleader facendo solo recensioni ma richiede una persona che non è affraid di scegliere un "combattere" nel corso di un pezzo di codice poco sviluppata, e deve essere una persona che si prende cura su come il codice dovrebbe essere. Non tutte le aziende assumono persone che in realtà si preoccupano di quello che fanno, e quelle cattive uova dovrebbero non IMO essere permesso di fare le revisioni del codice, che sono suscettibili solo per alzare le spalle e dire "OK" per cattivo codice.

In sostanza la revisione del codice è necessario per tutti i programmatori indipendentemente dall'esperienza. E 'il Controllo Qualità dello sviluppo del software, e una delle ragioni per l'Open Source può essere di altissima qualità.

EDIT: Il motivo è che un codice recensore oggi è esattamente lo stesso ruolo di manutentore tardi. Se il codice non ha senso per lui oggi, non avrà senso in seguito sia, rendendo i bug più costosi da riparare. Quindi, lo rendono oggi comprensibile, mentre lo sviluppatore ricorda ancora il codice. Anche il recensore può vedere insetti o omissioni che lo sviluppatore ha mancato.

Purtroppo pochissime vuole farlo, ma visti da un punto di vista dovrebbe essere obbligatorio.

Io lavoro in un luogo in cui revisione del codice è ormai un requisito, ma non era il meno 3 anni fa. Ha fatto un enorme miglioramento in nel nostro codice e nella capacità degli altri per mantenere il codice in seguito. Anche anziano, gli sviluppatori molto esperti commettono errori che possono facilmente e tranquillamente essere risolti con la revisione del codice prima di QA o peggio trova prima che il cliente li trova. Inoltre almeno una persona diversa lo sviluppatore originale è familiarità con il codice.

Spesso, quando un'organizzazione cerca qualcosa di nuovo ad esso, come abbiamo fatto con la revisione del codice, c'è molta resistenza al cambiamento. Ho visto quasi niente di tutto questo (eravamo Estatic per avere un reparto di QA formale troppo.) Con la revisione del codice. Ci vuole più o meno solo una o due recensioni per vedere il valore.

Ho trovato nuove tecniche che non avevo considerato sia nel fare una revisione del codice di lavoro di qualcun altro o di avere il mio codice recensione. Abbiamo trovato problemi di competenza con i nuovi assunti in tempi relativamente brevi avendo revisioni del codice e soprattutto da come hanno risposto alla revisione del codice. Abbiamo imparato ciò che le cose che sembrano perfettamente chiaro in questo momento nel bel mezzo di programmazione di quella sezione che non sarà chiaro nella manutenzione. Questo ha un valore inestimabile. Può essere che l'unica cosa necessaria è un commento sul perché qualcosa è stato fatto. Abbiamo trovato alcuni fraintendimenti fondamentali sulla nostra progettazione di database che dovevano essere corretti per una relazione effettivamente avere le informazioni corrette.

Spesso quello che ho visto in una revisione del codice è che, per il solo fatto di spiegare qualcosa a qualcun altro, lo sviluppatore avrà una svolta lampadina nella sua testa e capire che c'è un bug il recensore non ha visto .

E ragazzo può revisione del codice identifica quei programmatori cowboy che non seguiranno qualsiasi standard o usare strumenti mandato e il cui codice sarà quasi impossibile da mantenere sul da chiunque altro. E può imporre loro di ottenere con il programma o ottenere troppo.

Le persone più resistenti alla revisione del codice sono spesso le persone che l'organizzazione maggior parte delle esigenze di sbarazzarsi di perché sanno nei loro cuori il loro codice non può passare una revisione del codice.

Agile ragazzo avrebbe detto: "Non hai bisogno di una revisione del codice, basta fare i test di programmazione coppia e scrivere buoni":)

Codice recensione è un buon modo di diffondere knowlege e buone prassi attraverso un team. Nella mia esperienza è una buona idea per assicurarsi che tutto il codice viene recensione, e cercare di variare che rivede quale codice.

Nel codice miei attuali di tutti quanti squadra è rivisto allo stesso modo, ed entrambi programmatore e revisore devono essere esageratamente pignoli con il codice prima che possa essere rilasciato. Questo vale tanto per gli sviluppatori di alto livello in fase di revisione da parte degli sviluppatori più giovani, uno sviluppatore juniores rivedere un altro, o altri sviluppatori senior rivedere l'un l'altro. Se il recensore è inesperto o non si sente bene rivedere un particolare pezzo di codice poi si farà coppia con un altro sviluppatore (e forse anche lo sviluppatore originale) per fare la revisione come un gruppo.

Sono stato in attività per più di 20 anni, lavorando per le aziende di software e per diverse aziende e nessuno di questi luoghi ha avuto un processo di revisione del codice. Tuttavia, posso capire e apprezzare i vantaggi di avere uno. In sostanza, come li comprendo, dovrebbero essere utilizzati per garantire l'aderenza agli standard, che devono essere seguite in modo che altri possano mantenere più facilmente il codice in futuro. La leggibilità del codice potrebbe anche essere verificata in un processo di revisione, come anche questo farà in modo che la manutenzione può efficacemente il lavoro con il codice.

Al momento, io lavoro in un piccolo negozio dove sono l'unico sviluppatore. Di tanto in tanto abbiamo portato in appaltatori per aiutare con l'arretrato. Almeno uno o due di questi imprenditori hanno scritto il codice che non necessariamente incontrare i miei standard o delle società, ma ha funzionato bene ed era almeno un po 'comprensibile. Quando ho fatto notare questo problema fuori per la gestione, a loro non importava, che volevano solo sapere se ha fatto quello che abbiamo pagato loro di fare. Quindi, credo che dipende solo dalla società, e se pulita o meno, facile da mantenere il codice è il prodotto desiderato, o se vogliono solo qualcosa che funziona bene per i soldi.

Ovviamente come sviluppatore, e colui che deve mantenere il codice, vorrei lavorare con codice pulito che segue uno standard di qualche tipo, ma io non sempre avere questo lusso, così faccio la meglio e affrontare quello che ho, anche se questo significa a volte di dover ri-scrivere del codice nel mio standard.

Le revisioni del codice in grado di identificare i difetti in precedenza nel ciclo di vita del software quando i problemi sono più facili (e meno costoso) per fissare. A SmartBear abbiamo sviluppato un codice peer review strumento e hanno anche fatto un sacco di ricerca su come fare le revisioni del codice efficace. Sulla base dei dati dei nostri clienti, difetti trovati in revisione del codice sono 8-12X più conveniente per trovare e correggere i difetti che ha trovato in QA. Il risparmio sui costi da solo rende la revisione del codice vale la pena, ma non v'è più valore di questo. Code Review è un modo eccellente per tutto il team per imparare e migliorare, come gli sviluppatori di software.

Ci sono alcune trappole che possono causare le revisioni del codice a diventare meno efficaci, e sembra che la vostra organizzazione e 'colto in uno di essi. Fare la revisione del codice sul codice, non le persone. I titoli non significano nulla in una revisione del codice. Appello all'autorità (si deve fare a modo mio, perché io sono il responsabile del team) fare più male che bene. Insegnate invece. ingegneri senior dovrebbero spiegare perché dovrebbe essere fatto la loro strada, non solo la domanda che si tratta. Se stai attraversando un periodo difficile spiegare un concetto, si tratta di un'esperienza di apprendimento anche per te. Entrambi di voi sarà sviluppatori migliori per lo sforzo di mettere in.

Credo che il codice di revisione tutto il codice è eccessivo. La quantità di tempo necessario per rivedere tutto il codice potrebbe essere meglio spesi altrove. Alterntivley Credo che il codice critico e o pezzi particolarmente complessi hanno bisogno di revisione del codice, ma di certo non ogni riga di codice.

A mio parere, il codice che sta per essere utilizzato da una società, se è stato scritto da un Junior o sviluppatore senior, dovrebbe sempre essere rivisto. Perché? Perché quello che se il codice ha avuto diversi bug? E se, nel corso del tempo è stato utilizzato questo codice, il programma si è schiantato? Per interrompere queste cose accada, tutto il codice dovrebbe essere rivisto prima dell'uso.

Ma che dire di quelle aziende che non la revisione del codice? Sono probabilmente le aziende che hanno un sacco di problemi tecnici e un sacco di, come dicono i consumatori, "crash" ;-).

Quindi, mi permetta di rispondere a tutte le vostre domande:

  • Sì, il processo di revisione è necessaria.
  • Perché? A causa dei motivi che ho detto sopra.

Qual è la differenza con interferire con le vostre idee prima di controllare nel codice (recensione) o successivamente a causa di un bug, diventando troppo intelligente / difficile da capire, o non seguire pratiche standard accettati? È il tuo ego?

Non è possibile disreguard i meriti di revisione del codice o qualsiasi altra cosa solo perché è in corso di attuazione male da un membro del team meno qualificati non si rispettano. Code Review non è un processo molto complesso che solo pochi programmatori eccellenti sono in grado di cogliere. Non sono sicuro che ci sono molti programmatori o scrittori professionisti che sono in grado o hanno il tempo di auto-edit.

Hai mai tornato ad una riga di codice, pochi mesi dopo e mi chiedevo cosa stavo pensando? Ci sarebbe una migliore possibilità di catturare con una revisione del codice. Avete preso e si è solo leggermente migliore rispetto al programmatore si erano poco fa -. Spero

IMO una revisione del codice dovrebbe essere essenziale per tutti gli sviluppatori, ma solo quando la gente che fa la revisione sono competenti se stessi. Nel codice passato ho avuto respinto in una recensione, perché, non scherzo, ho seguito SOLID, ha fatto un po 'di Dependency Injection e aveva il codice organizzati in spazi dei nomi e le cartelle in base alla progettazione logica, e comprendeva una piccola suite di test di unità per verificare il codice. Il codice è stato respinto come "troppo complicato" e mi è stato detto di utilizzare una classe che smushed tutto insieme e rimuovere le prove perché non era come l'azienda ha scritto il codice.

Una revisione del codice del genere è inutile, ma una revisione del codice con un team competente può qualcosa spesso illuminano circa il disegno (ad esempio, perché si dovrebbe fare X e Y, ma non Z) oppure indicare un difetto vero e proprio (ad esempio facendo X causerà Y di fallire per motivi non corretti).

Naturalmente Code Review non è necessarie . Poi di nuovo, né lo sono i test, l'integrazione continua, controllo del codice sorgente, il coinvolgimento del cliente, profilatura, l'analisi statica, hardware decente, un solo clic costruisce, bug tracking, l'elenco potrebbe continuare.

insieme al codice recensioni, le cose che ho citato sopra sono strumenti che aiutano a garantire la qualità del software. Con una combinazione di abilità, fortuna, tempo e determinazione; si possono di fornire software di qualità, senza nessuna di queste cose, ma è più probabile che si non .

Nel vostro scenario, non c'è nulla da essere confuso circa. Non ogni organizzazione si abbandona a ogni best practice. Essi possono essere in disaccordo con esso, può entrare in conflitto con una buona pratica differente che implementano, oppure possono considerare che il sovraccarico di attuazione è troppo grande per loro a questo punto nel tempo. A seconda delle loro circostanze, possono essere corrette in questo modo, o possono essere fare una falsa economia. Per alcuni strumenti, (controllo esempio fonte) il rapporto di recupero / sforzo è così buono che utilizzo è una facile soluzione; per altri è meno chiaro.

Non v'è dubbio che la revisione del codice è una pratica che introduce un overhead significativo. A causa di questo, le organizzazioni cercheranno di ridurre al minimo il carico di, o per non farlo affatto, o solo da farlo in determinate situazioni (ad esempio per un membro del team juniores, o di un cambiamento particolarmente pelosa). Non è sempre ovvio che ripaga di più (a prendere insetti, riducendo il debito tecnica o la condivisione delle conoscenze) di quanto costa. La maggior parte di quel recupero è difficile da quantificare, mentre la sua molto facile contare il numero di ore-uomo vostra organizzazione spende facendo recensioni. Il bit più semplice da quantificare (ridotto numero di bug) è facile da attributo ad altri fattori (ad esempio, "naturalmente ha meno bug, è più maturo").

Il gioco di calcio online in Turchia. Un sacco di utenti e maestri del gioco ci aiuta sulla funzionalità. Inoltre essi danno commenti sulle caratteristiche necessarie. Quindi penso che, se avete un sacco di utenti, test di funzionalità può essere fatto per aiutare o di ottenere distintivi. Collobration di sviluppatori, maestri di giochi e gli utenti con forum, team di supporto e ambienti di test privati ??a creare un progetto sociale.

revisioni del codice sicura e la condivisione di esperienze tra team di sviluppo è necessario, ma se non è critica non devi sforzarti.

Credo che il modo verbose ispezione secondo partito è dipende dal vostro ciclo di vita, se sei più agile, o più cascata nei vostri processi. Penso che sia ragionevole da fare disegni di alto livello / ispezioni, così come più controlli di progettazione del livello di dettaglio. Penso che sia anche un bene di coinvolgere diversi membri di una squadra di ispezionare.

Loro sono assolutamente necessario dal momento che hanno poca esperienza.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
scroll top