I miei colleghi dovrebbero rivedere il codice degli altri dal sistema di controllo del codice sorgente?

Direi SÌ!

Due rapidi motivi per questo:

1) Se il codice è in produzione, non è possibile presumere che sia corretto. Qualsiasi modifica da qualche parte nel sistema può introdurre bug. Penso che sia molto importante che il codice venga controllato regolarmente. In questo modo, il refactoring viene effettuato su base regolare, mantenendo il codice pulito e "più" corretto (probabilmente aggiornato è meglio).

2) Essere in grado di leggere il codice è un'abilità molto importante se stai per diventare un programmatore. E un'abilità è, 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 su ciò che sta accadendo.

Non penso che dovresti sentirti spiato. Accetta qualsiasi critica che qualcuno ti dà (se è valido, naturalmente). E sentiti libero di dare ad altre persone una VALIDA critica. È il modo in cui apprendiamo. Una volta che smettiamo di imparare (o vogliamo fermarci), allora ci sono grossi problemi.

Se il collega ha fornito feedback positivi e costruttivi, questa è una cosa fantastica e dovresti apprezzarla molto.

Questo WILL cattura gli errori a cui non hai pensato durante la scrittura. Questo WILL ti porterà a scrivere codice migliore perché sai che gli altri lo vedranno.

Sarebbe salutare se l'intero team effettuasse le revisioni del codice invece di una sola persona. Idealmente tutti inviteranno qualcuno a rivedere il loro codice dopo il completamento. È utile mantenerlo informale (mantieni i manager lontani) e lascia che il revisore ti parli attraverso i suoi risultati. Idealmente il revisore fornisce solo feedback e non modifica il codice, ovviamente puoi accoppiarlo un po '.

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

Riguardo all'aspetto del tempo, la teoria è che ti farà risparmiare tempo. I difetti successivi si trovano più costosi ottengono, il principio del fail fast. La revisione del codice peer può catturare un bel po 'di problemi.

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

Guardo il nostro sistema di controllo delle versioni in modo simile. Il nostro codebase è troppo grande per guardare ogni riga, ma cerco di ottenere un alto livello per la maggior parte dei cambiamenti. Guardo anche per i controlli che hanno maggiori probabilità di avere effetti collaterali e rivederli riga per riga. Per il tempo minimo che trascorro facendo questo, il guadagno è enorme. (Nota anche: io non sono l'unico sviluppatore del nostro team con questa abitudine.)

Questo tipo di recensione tende a catturare bug o ad invocare discussioni su base settimanale. Ciò consente di risparmiare tempo durante il QA. Le discussioni vanno dalle migliori pratiche alla progettazione dell'algoritmo e altro ancora. La chiave su questo fronte è che tutti la considerano costruttiva.

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

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

IMHO se qualcuno indica qualcosa di sbagliato nel tuo codice, devi accettarlo e imparare da loro 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 attivamente sviluppata, impegnata nel repository centrale, 2 lingue principali, poche altre lingue, enormi makefile per 4 piattaforme.

È una pessima pratica . Un giorno ho scoperto che non riesco a catturare tutto a causa della robustezza. L'altro argomento contro questo è la soggettività - tutti possono sbagliare.

È meglio che gli sviluppatori rivedano i reciproci codici e che ci sia qualcuno con esperienza per prendere decisioni definitive e definire le direzioni.

Valutazioni del codice all'interno di un team (utilizzando 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 la prima volta sia ben pensato e abbia attraversato il cervello di più di una persona.

Questo è successo nella mia squadra una volta. Sfortunatamente ha portato a un gioco di colpa. La gente aspettava continuamente che gli altri controllassero il codice e cercassero sempre di trovare qualcosa di sbagliato in essa e giocavano sempre il gioco della colpa.

Spero che tu abbia un pubblico più maturo.

Questa è una pratica abbastanza normale nell'industria. Le aziende in cui ho lavorato hanno linee guida molto restrittive per la revisione del codice. Uno addirittura non ti lascerebbe commettere a meno che il codice non sia stato revisionato.

Non offendersi o sentirti osservato. Pensala come una rete di sicurezza e un'esperienza di apprendimento.

In un precedente lavoro, lo sviluppatore senior guardava e revisionava tutti i check-in e ricevevo spesso feedback eccellenti che mi hanno aiutato a diventare uno sviluppatore migliore.

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

Questa pratica sicuramente catturerà bug e migliorerà l'intera squadra, se la abbracci.