Sei pronto per una revisione del codice come sviluppatore?

Sto cercando alcune idee qui.

Ho letto l'articolo Come dovrebbero revisioni del codice essere effettuate e Codice recensioni, quali sono i vantaggi? che sono stati molto istruttivi ma ho ancora bisogno di più chiarezza sulla domanda qui sotto.

La mia domanda è,

1. Essendo lo sviluppatore target, puoi suggerire alcune best practice che uno sviluppatore può incorporare prima che il suo codice venga esaminato.

   • Attualmente pratico i seguenti metodi

     • PPT per un flusso logico
     • Commenti dettagliati.

Problema: anche se ho implementato le pratiche di cui sopra, non aiutano la revisione. Il problema che ho dovuto affrontare è che, quando si fa riferimento a determinate logiche, continuo a cercare l'implementazione e il flusso e nel processo viene sprecato troppo tempo e mi innervosisco.

Penso che molti sviluppatori passerebbero anche quello che sto attraversando.

Quindi, in base ai dettagli forniti dall'OP, sembra che la domanda sia: "come posso imparare il mio codice in modo che quando mi viene chiesto di trovare X o spiegare Y, sono in grado di rispondere rapidamente".

Alcuni suggerimenti a cui posso pensare:

• Durante la codifica, è necessario dedicare del tempo per apprendere e comprendere il proprio codice. Questo potrebbe essere ciò che il tuo TL sta cercando di farti capire in non tante parole. Essendo un TL del progetto attuale, ho fatto molte revisioni del codice negli ultimi 11 mesi e noto una pratica di alcuni sviluppatori per cercare "codice di esempio" nella nostra base di codice o altrove (google , ecc ...) e copiarlo / incollarlo. Personalmente, non lo sopporto perché mentre il loro codice supera i semplici test unitari, non capiscono cosa sta effettivamente facendo, quindi non siamo mai sicuri che non ci sia • un caso limite o una condizione di guasto prevista che potrebbe verificarsi.

• Come corollario dell'istruzione precedente, se devi copiare / incollare, prova a copiare / incollare solo il codice che hai scritto in precedenza e che capisci. È certamente ok "prendere in prestito" l'idea di altre persone, ma in tal caso, riscrivere il loro codice riga per riga perché, mentre la scrivi, otterrai una migliore comprensione di ciò che fa. Se stai utilizzando API esterne, anche se hai un esempio che utilizza quell'API, prenditi comunque qualche minuto per trovare un riferimento e scoprire come funziona l'API. Non dare per scontato che se ha funzionato prima, funzionerà anche nella tua situazione.

• Leggi e impara ad amare il principio DRY . Molte volte ciò che sei tentato di copiare / incollare potrebbe essere collocato in una posizione comune (funzione separata, classe separata, libreria separata ...)

• Leggi e impara ad amare i principi SOLIDI e mentre ci sei, rivedi KISS che è già stato menzionato da mouviciel. Questi principi sono tutti orientati alla produzione di codice molto conciso, pulito e modulare. Se ci sono grandi classi e grandi funzioni all'interno di quelle, sarà chiaramente molto più difficile trovare cose e, soprattutto, provare a spiegare cosa fa il codice. D'altra parte, se segui (o almeno provi a seguire) SRP e rendi ogni classe / funzione responsabile di una sola cosa, il tuo codice sarà piccolo e molto leggibile.

• Prendi una copia di Clean Code . Ottimo libro Parla della scrittura di codice autoesplicativo e di facile lettura, manutenzione ed estensione. Se fai pratica nella scrittura di codice facile da leggere, non dovresti avere problemi a leggere il tuo codice nelle recensioni del codice. E questa è la parte divertente, ho chiesto alle persone di leggere il proprio codice o semplicemente di dirmi cosa rappresentavano le variabili e non potevano rispondere anche se hanno scritto quel codice (classi nuove di zecca, non legacy) solo una settimana fa . La buona denominazione fa molta strada.

• Se dopo tutta la semplificazione e il refactoring, hai ancora una funzione che deve eseguire un qualche tipo di algoritmo che non è molto evidente, prenditi il ​​tempo e scrivi un blocco di commenti in quella funzione che spiega l'algoritmo. Non solo sarà utile quando devi modificare quella funzione tra 2 mesi, ma se ti imbatti in un'imboscata in una revisione del codice, potresti semplicemente rileggere ciò che hai scritto.

• Se dopo tutti gli elementi sopra, ti trovi ancora nei guai? sei nuovo nel team e ti viene chiesto di lavorare con un sacco di codice legacy? In tal caso, è possibile che il tuo TL sia un A $$ e potresti essere proattivo chiedendogli prima della riunione di andare piano e di non perdere il tempo di tutti i soggetti coinvolti. Quando nuove persone si uniscono a un team, TL deve avere abbastanza pazienza perché lavorare in una nuova piattaforma, nuovo prodotto, nuove persone, nuovo ambiente richiede molta concentrazione da una nuova persona e quella persona all'inizio mancherà di alcuni dettagli. Funziona come progettato e il tuo TL dovrebbe accettarlo.

• Se dopo tutti gli articoli sopra, hai ancora la sensazione di avere orribili recensioni di codice. Parla con il tuo TL. A volte le persone si sentono male a causa della natura delle riunioni di revisione del codice quando in realtà TL è perfettamente felice con te. Quando eseguo le revisioni del codice, il mio obiettivo è quello di evidenziare ciò che deve essere modificato, assicurarsi di aver compreso le modifiche e andare avanti. Molte volte non ho tempo di essere educato e alcune persone si difendono e cercano di rispondere a tutti i miei commenti. In quelle situazioni, la riunione di revisione del codice si interrompe, quindi tendo a interromperli e andare avanti. In genere, dopo l'incontro, parlerei con i nuovi ragazzi per assicurarmi che comprendano il processo e che non sia nulla di personale. Dopo alcune revisioni del codice, le persone sono generalmente molto più a loro agio.

Le pratiche variano, ma nella mia esperienza:

• Non fare nulla di speciale per il codice. È naturale aggiungere un po 'di più al tuo codice quando apprendi che verrà rivisto e non c'è nulla di male nel correggere cose ovvie come errori di ortografia e simili. Ma non entrare e aggiungere molti commenti dettagliati o modificare in altro modo il codice solo perché è programmato per la revisione.

• Il codice viene preparato e distribuito ai revisori con largo anticipo rispetto alla revisione. Questo di solito viene fatto da una terza parte neutrale, probabilmente il facilitatore della revisione del codice. Se stampato, il codice dovrebbe essere abbastanza piccolo da non avvolgere le linee troppo spesso, ma abbastanza grande da consentire a tutti di leggerlo facilmente. Stampalo in formato orizzontale se è quello che serve.

• Il codice deve essere stampato o visualizzato con numeri di riga . Preferibilmente, il numero dovrebbe continuare da un file all'altro. È molto più facile fare riferimento alla "linea 3502" rispetto alla "linea 238 di foo.c" e avere i numeri consente a tutti di parlare di linee specifiche senza perdere tempo a trovarle.

• Dovrebbe esserci sicuramente un facilitatore , a proposito. Il suo compito è quello di impedire che la recensione venga impantanata in minutia, impedire che diventi personale o riscaldata e limitare rigorosamente la durata della recensione.

• Come autore, è necessario rivedere il codice da soli prima della riunione di revisione. Annota le modifiche che suggeriresti se questo fosse il codice di qualcun altro. Questo fa muovere la tua memoria di codice che potresti non aver visto in pochi giorni e ti aiuta anche a esercitarti a guardare il tuo codice con un occhio critico. Dopo aver esaminato alcune recensioni, sia come revisore che come autore, scoprirai che le tue note saranno più simili a quelle del resto del gruppo.

• Preparati a prendere appunti durante la revisione. Questa non dovrebbe essere la tua principale preoccupazione: qualcun altro dovrebbe registrare gli elementi di azione su cui il gruppo concorda in modo che tu possa concentrarti sulla spiegazione del codice e sull'ascolto del feedback. Ma ci saranno momenti in cui ricevi un feedback prezioso che non è un elemento di azione e dovresti correggere le cose nel momento in cui si verificano.

• Ricorda che non è personale. È difficile evitare di sentirsi (e agire) sulla difensiva durante una recensione. Va bene spiegare il tuo codice se pensi che sia stato frainteso, ma più di ogni altra cosa prova ad ascoltare.

Un'altra cosa da aggiungere alle altre risposte: per semplificare i revisori del codice formale , condurre MOLTE revisioni informali del codice! Per esempio:

"Ehi Bob, posso mostrarti come ho implementato la funzione foo ()?" "Ehi Steve, puoi dare un'occhiata a questo diagramma di classe e farmi sapere cosa ne pensi?" "Ehi Karen, puoi aiutarmi a riflettere su questo problema? Penso di avere una buona soluzione, ma potrei usare il tuo aiuto ..."

Rendi l'abitudine regolare. Quando coinvolgi i tuoi colleghi all'inizio del processo di progettazione, tu:

• Costruisci relazioni
• Ottieni nuove informazioni sul problema
• Migliora la tua capacità di spiegare il problema / la soluzione a portata di mano
• Risparmia tempo più tardi nelle revisioni formali del codice