I miei colleghi dovrebbero rivedere a vicenda il codice dal sistema di controllo del codice sorgente?

Questa è la mia storia: uno dei miei colleghi usa per rivedere tutto il codice, ospitato nel sistema di revisione. Non sto parlando di un'adeguata revisione dei cambiamenti nelle parti a cui appartiene. Guarda il file di codice in un file, riga per riga. Ogni nuovo file e ogni modificato. Mi sento proprio come essere spiato!

La mia ipotesi è che se il codice fosse già ospitato nel sistema di controllo, almeno dovresti considerarlo fattibile. La mia domanda è: forse sono troppo paranoico e la pratica di rivedere il codice di ogni altro è buona?

PS: Siamo un team di soli tre sviluppatori e temo che se ci saranno più di noi, il collega non avrà il tempo di rivedere tutto il codice che scriveremo.

Direi di si!

Due motivi rapidi per questo:

1) Se il codice è in produzione, non si può presumere che sia corretto. Qualsiasi modifica in altre parti del sistema può introdurre bug. Penso che sia molto importante che il codice venga controllato regolarmente. In questo modo, il refactoring viene eseguito regolarmente, mantenendo il codice pulito e "più" corretto (l'aggiornamento è probabilmente migliore).

2) Essere in grado di leggere il codice è un'abilità molto importante se vuoi diventare un programmatore. E un'abilità che è, qualcosa su cui devi lavorare. Per ogni programmatore che inizia a lavorare su una base di codice esistente, se non è abituato a leggere il codice di altre persone, c'è una curva di apprendimento ripida che cerca di aggiornarsi con quello che sta succedendo.

Non credo che dovresti sentirti spiato. Accetta qualsiasi critica che qualcuno ti dà (se è valido ovviamente). E sentiti libero di dare agli altri una VALIDA critica. È il modo in cui impariamo. Una volta che smettiamo di imparare (o vogliamo smettere), allora ci sono grandi problemi.

Se detto collega fornisce un feedback positivo e costruttivo, questa è una cosa fantastica e dovresti apprezzarla molto.

Questo SARA catturare gli insetti non hai pensato di quando scriverlo. Questo SARA provocare in voi scrivere codice migliore, perché si sa che gli altri lo vedranno.

Sarebbe salutare se l'intero team eseguisse la revisione del codice anziché una persona. Idealmente tutti dovrebbero invitare qualcuno a rivedere il proprio codice dopo il completamento. È utile tenerlo informale (tenere lontano i manager) e lasciare che il revisore ti parli attraverso i suoi risultati. Idealmente, il recensore fornisce solo feedback e non esegue modifiche al codice, ovviamente potresti abbinarlo un po '.

Aiuta davvero ad avere standard di codifica per evitare che le discussioni di revisione riguardino costantemente lo spazio bianco e lo stile del codice. Avere alcune analisi del codice statico su una macchina di compilazione può essere utile per tenere fuori anche alcune discussioni.

Per quanto riguarda l'aspetto del tempo, la teoria è che ti farà risparmiare tempo. I guasti successivi si trovano più costosi ottengono, falliscono il principio veloce. La revisione del codice peer può rilevare diversi problemi.

Il tuo collega sembra uno sviluppatore diligente, dovresti seguire il suo esempio.

Guardo il nostro sistema di controllo della versione in modo simile. La nostra base di codice è troppo grande per guardare ogni riga, ma cerco di ottenere un livello elevato per la maggior parte delle modifiche. Guardo anche i check-in che hanno maggiori probabilità di avere effetti collaterali e li rivedo riga per riga. Per il tempo minimo che passo a fare questo, il payoff è enorme. (Nota anche: non sono l'unico sviluppatore del nostro team con questa abitudine.)

Questo tipo di revisione tende a rilevare bug o a invocare discussioni su base settimanale. Ciò consente di risparmiare tempo durante l'esecuzione del QA. Le discussioni spaziano dalle migliori pratiche alla progettazione di algoritmi e altro ancora. La chiave su questo fronte è che tutti lo considerano costruttivo.

Personalmente, mi dà anche una maggiore comprensione di ciò che sta accadendo in altre parti della base di codice che non tocco regolarmente. Quando gli altri hanno bisogno di aiuto, sono in grado di saltare più rapidamente. Inoltre, quando compaiono nuove idee, posso approfittarne prima.

Lo senti come spiato (!)? Ma dal punto di vista del collega direi che sta facendo le cose giuste per lo sviluppo della sua carriera. Leggi il codice degli altri e scopri come progettano e implementano la logica, questo ti farà guadagnare molto!

IMHO se qualcuno sottolinea qualcosa di sbagliato nel tuo codice, devi accettarlo e imparare da loro su come scrivere un buon codice

Durante 6-7 mesi stavo facendo lo stesso. Non per spiare, ma per controllare la qualità. Ogni singola riga del codice per un'applicazione sviluppata attivamente, impegnata nel repository centrale, 2 lingue principali, poche altre lingue, enormi makefile per 4 piattaforme.

È una brutta pratica . Un giorno ho scoperto che non posso catturare tutto a causa della robustezza. L'altro argomento contro questo è la soggettività: tutti potrebbero sbagliarsi.

È meglio quando gli sviluppatori si rivedono a vicenda i codici e c'è qualcuno con esperienza per prendere le decisioni finali e definire le direzioni.

Le revisioni del codice all'interno di una squadra (usando fisheye , crogiolo o altri strumenti) sono estremamente importanti e utili. l'unica cosa migliore è la programmazione di coppie dirette per assicurarsi che il codice che entra nel sistema per la prima volta sia ben studiato e sia passato attraverso il cervello di più di una persona.

Questo è successo una volta nella mia squadra. Purtroppo ha provocato un gioco di colpa. Le persone hanno atteso continuamente che gli altri effettuassero il check-in del codice e cercassero sempre di trovare qualcosa di sbagliato in esso e giocassero continuamente al gioco della colpa.

Spero che tu abbia un pubblico più maturo.

Questa è una pratica abbastanza standard nell'industria. Le aziende in cui ho lavorato hanno linee guida per la revisione del codice molto rigide. Uno non ti permetterebbe di impegnarti a meno che il codice non fosse stato rivisto.

Non offenderti, né sentirti guardato. Pensalo come una rete di sicurezza e un'esperienza di apprendimento.

In un precedente lavoro, lo sviluppatore senior ha guardato e rivisto tutti i check-in e spesso ho ricevuto feedback eccellenti che mi hanno aiutato a diventare uno sviluppatore migliore.

Nel mio lavoro attuale, guardo molti dei check-in e tre giorni fa ho trovato un bug e avvisato lo sviluppatore.

Questa pratica assolutamente sarà catturare gli insetti e rendere la vostra intera squadra migliore, se abbracciate.