Essere preparato per una revisione del codice come sviluppatore?

Quindi, sulla base dei dettagli forniti da OP, sembra che la domanda sia: "come imparo il mio codice in modo che quando viene chiesto di trovare X o spiegare Y, sono in grado di rispondere rapidamente."

Pochi 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 comunicare con te in così poche parole. Essendo un TL sul progetto corrente, ho fatto molte revisioni del codice negli ultimi 11 mesi e noto che alcuni sviluppatori cercano "codice di esempio" nel nostro codice base 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 facendo in realtà, quindi non ci è mai garantito che non ci sia t un caso limite o una condizione di errore prevista che potrebbe verificarsi.

• Come corollario alla dichiarazione precedente, se devi copiare / incollare, prova a copiare / incollare solo il codice che hai scritto in precedenza e che hai capito. È certamente ok per "prendere in prestito" l'idea di altre persone, ma in tal caso, riscrivi il codice riga per riga perché, mentre lo stai scrivendo, otterrai una migliore comprensione di ciò che fa. Se si utilizzano API esterne, anche se si dispone di un esempio che utilizza tale API, richiedere comunque alcuni minuti per trovare un riferimento e imparare come funziona l'API. Non dare per scontato che, se funzionasse prima, funzionerà anche nella tua situazione.

• Leggi e impara ad amare il principio ASCIUTTO . Un sacco di volte ciò che si è tentati di copiare / incollare potrebbe essere collocato in una posizione comune (funzione separata, classe separata, libreria separata ...)

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

• Prendi una copia di Pulisci codice . Ottimo libro. Parla di scrivere un codice che è auto esplicativo e facile da leggere, mantenere ed estendere. Se ti eserciti a scrivere codice che è 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 che cosa rappresentavano le variabili e non potevano rispondere anche se hanno scritto quel codice (classi nuove, non legacy) solo una settimana fa . Una buona nomenclatura è molto lunga.

• Se dopo tutto la semplificazione e il refactoring, hai ancora una funzione che deve eseguire un qualche tipo di algoritmo che non è molto apparente, prenditi il tempo e scrivi un blocco di commenti in quella funzione spiegando l'algoritmo. Non solo sarà utile quando dovrai modificare quella funzione tra 2 mesi, ma se tenti un'imboscata in una revisione del codice, sarai in grado di leggere semplicemente ciò che hai scritto.

• Se dopo tutti gli articoli sopra, ti trovi ancora nei guai? sei nuovo nel team e hai chiesto di lavorare con un sacco di codice legacy? In tal caso, potrebbe essere che il tuo TL sia un A $$ e potresti essere proattivo chiedendogli prima della riunione di andare facile e non perdere tempo da tutte le persone coinvolte. Quando nuove persone si uniscono a un team, TL deve avere abbastanza pazienza perché lavorare su una nuova piattaforma, un nuovo prodotto, nuove persone, un nuovo ambiente richiede molta concentrazione da una nuova persona e alla persona mancheranno alcuni dettagli all'inizio. Funziona come Progettato e il tuo TL dovrebbe accettarlo.

• Se dopo tutti gli elementi precedenti, ritieni di avere recensioni di codice orribili. 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 cambiato, assicurati di comprendere le modifiche e andare avanti. Molte volte non ho tempo per essere educato e alcune persone si difendono e cercano di rispondere a ciascuno dei miei commenti. In quelle situazioni la riunione di revisione del codice si ferma, quindi tendo ad interromperli e andare avanti. Generalmente, dopo l'incontro, parlerei con i nuovi ragazzi per assicurarmi che capiscano il processo e che non sia niente di personale. Dopo poche revisioni di codice, le persone sono generalmente più a loro agio.

Le pratiche variano, ma nella mia esperienza:

• Non fare nulla di speciale per il codice. È naturale spiffare il tuo codice un po 'di più quando si impara che verrà rivisto, e non c'è nulla di male nel correggere cose come errori di ortografia e simili. Ma non entrare e aggiungere molti commenti dettagliati o altrimenti cambiare il codice solo perché è in programma per la revisione.

• Il codice viene preparato e distribuito ai revisori con largo anticipo rispetto alla revisione. Di solito viene eseguito da una terza parte neutrale, probabilmente il facilitatore della revisione del codice. Se stampato, il codice dovrebbe essere abbastanza piccolo da non incappare troppo spesso sulle righe, ma abbastanza grande da consentire a chiunque di leggerlo facilmente. Stampa in formato orizzontale se è quello che serve.

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

• Ci dovrebbe essere sicuramente un facilitatore , btw. Il suo compito è di impedire che la recensione si impantanasse in minutia, impedisca che diventi personale o surriscaldata e limita strettamente la durata della revisione.

• Come autore, dovresti esaminare il codice da solo prima della riunione di revisione. Annota le modifiche che suggeriresti se si trattasse del codice di qualcun altro. Questo fa impazzire la memoria del codice che potresti non aver visto in pochi giorni e ti aiuta anche a fare pratica guardando il tuo codice con occhio critico. Dopo aver passato alcune recensioni, sia come revisore che come autore, scoprirai che le tue note corrisponderanno più strettamente 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 è d'accordo, in modo che tu possa concentrarti sulla spiegazione del codice e sull'ascolto del feedback. Ma ci saranno momenti in cui ricevi feedback preziosi che non sono un elemento di azione, e dovresti raddrizzare tali cose non appena si verificano.

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

Un'altra cosa da aggiungere alle altre risposte: per rendere i revisori di codice formali più facili, conduci molte LOT di recensioni di informali ! Ad esempio:

"Ehi Bob, posso mostrarti come ho implementato la funzione foo ()?" "Ehi, Steve, puoi dare un'occhiata a questo diagramma di classe e fammi 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 questa abitudine normale. 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 dopo in revisioni di codice formali