Risposta breve
Devo correggere il codice da solo?
No.
Devo dare loro un feedback sul processo di revisione e lasciare che facciano le correzioni secondo le mie istruzioni?
Sì. Secondo i tuoi suggerimenti , non le istruzioni . Le istruzioni sembrano troppo autorevoli.
E in tal caso, come posso dare questo feedback, riempire un determinato documento modello e inviarlo a loro, o c'è qualche software che mi aiuterà a contrassegnare le cose con problemi all'interno dei file di codice in cui potranno successivamente verificarlo? (Sto usando Visual Studio).
Utilizzare uno strumento per fornire il feedback. Puoi usare Visual Studio.
Risposta lunga
Usavo Visual Studio ma dovevo costantemente chiedere ad altri sviluppatori: "Ehi, puoi inviarmi il tuo lavoro in modo da poterlo rivedere?" Non mi è piaciuto e non ha mai funzionato molto bene. Ora uso Review Assistant perché posso iniziare una recensione guardando i check-in. Non ho bisogno di fare affidamento su un altro sviluppatore che mi invia lavoro per la revisione. Mi aiuta anche a contrassegnare gli articoli come difetti, o semplicemente contrassegnare gli oggetti che devono essere guardati dall'autore. Questo funziona per il nostro team perché, una volta avviata una recensione, rimane nella bacheca delle recensioni e non si perde nella traduzione. Questo è integrato con Visual Studio. Come ho già detto, Visual Studio ha anche il suo processo di revisione nativo, ma trovo che abbia dei limiti e il processo non è naturale; pertanto, utilizzo Review Assistant.
Questo strumento aiuta anche con il processo avanti e indietro, discussioni ecc.
Il processo, più o meno, è il seguente:
Esamino qualcosa, quindi lo invio all'autore (nel tuo caso junior dev). Apportano modifiche e poi lo rispediscono. Guardo le modifiche e fornisco feedback. Se sono bravo con le modifiche, chiudo la recensione. Altrimenti va avanti e indietro. A volte, se c'è troppo avanti e indietro, vado semplicemente alla loro scrivania e userò una lavagna: accelera davvero il processo.
Le revisioni del codice sono un'area sensibile, quindi fai molta attenzione alla scelta del testo. Non lo dico mai a nessuno
Scarsa scelta del testo
Ho esaminato il tuo codice e ci sono alcuni elementi che devi modificare.
Dico invece questo:
Migliore scelta del testo
Ho esaminato il tuo codice e ho bisogno di aiuto. Potete per favore rivedere gli articoli che vi ho inviato e vedere se potete chiarire alcune delle mie domande?
Questo fa pensare all'autore:
- Ho bisogno di aiuto in modo che non entrino in modalità difensiva.
- Sembra che siano i recensori, non io. Tecnicamente parlando, dal momento che sto chiedendo loro di dare un'altra occhiata e cambiare alcune cose, sono un po 'come il recensore.
Queste semplici scelte di parole mi hanno aiutato enormemente.
Non sottovaluto mai gli sviluppatori minori. Ho lavorato con alcuni sviluppatori senior (oltre 10 anni di esperienza) e il codice era peggio di uno studente in cooperativa junior. Quindi solo perché sono senior o junior non è poi così importante; il loro lavoro è davvero ciò che parla più forte di anni di esperienza.
Spesso, per incoraggiare i giovani sviluppatori e farli partecipare alle recensioni, invierò loro qualcosa da rivedere per me: qualcosa che possono capire, qualcosa che troveranno stimolante ma non totalmente al di là di loro. Posso esprimerlo come di seguito:
Potete per favore rivedere qualche codice per me perché non riesco a capirlo.
Questo mi aiuta di nuovo molto. Questo aiuta perché dimostra chiaramente che io non sono l'unico a fare recensioni, ma fanno anche recensioni e fanno anche parte del processo. Mostra che l'idea è quella di produrre un codice buono e pulito e chiedere aiuto se necessario. Il processo di revisione è una cultura, quindi abbiamo davvero bisogno di lavorarci.
Ora alcune persone potrebbero preoccuparsi che se fanno quanto sopra, gli sviluppatori junior perderanno rispetto perché hanno appena fatto qualcosa che non potresti fare. Ma questo è lontano dalla verità: chiedere aiuto mostra umiltà. Inoltre ci sono molte situazioni in cui puoi brillare. Infine, se questa è la tua paura, hai problemi di autostima. Infine, forse non lo so davvero: voglio dire che alcuni di questi sviluppatori hanno algoritmi nuovi nella loro testa perché li hanno appena studiati un mese fa.
Comunque, torniamo a junior e recensioni. Dovresti vedere lo sguardo sui loro volti quando lo capiscono e mi inviano una risposta. Allora potrei dire loro: "OK, lasciami fare le modifiche e, se sei soddisfatto, per favore chiudi il problema."
Sono fantastici avere il potere di guardare il mio lavoro e dire: "Sì, i tuoi cambiamenti sono buoni. Ho chiuso il problema."
Non aggiorno mai il codice da solo perché:
- L'autore non imparerà da quello.
- È come se stessi dicendo: "Spostati di lato, lascia che ti mostri come è fatto. Il mio codice è migliore del tuo."
- Perché dovrei? Questo è più lavoro per me.
Ma suggerirò idee e frammenti di codice nei miei commenti per aiutare l'autore. Si prega di notare che a volte le mie recensioni chiedono semplicemente all'autore che non capisco il loro codice; potrebbe non esserci nulla di sbagliato nel loro codice. Potrebbero aver bisogno di cambiare i nomi delle variabili, aggiungere commenti ecc. Quindi, non saprò nemmeno cosa cambiare in quel caso; solo loro lo faranno.
Se continui a fare recensioni, prima o poi avrai una buona idea del livello di conoscenza di ogni sviluppatore del team. Sapere questo è davvero utile e devi sfruttarlo e liberarlo. Ecco come: se rivedo un po 'di codice e vedo ovvie aree di miglioramento e so che anche un altro sviluppatore potrebbe catturarlo, lo farò invece esaminare. Qualcosa del tipo "Ehi, vedo alcune aree che possono essere migliorate. Puoi per favore rivederlo in modo più dettagliato e inviare i tuoi commenti all'autore?" Funziona alla grande anche perché ora ho altri 2 sviluppatori che lavorano tra loro.
Se sto rivedendo un po 'di lavoro e noto qualcosa di cui l'intera squadra può trarre vantaggio, creerò uno scenario ipotetico e spiegherò il problema in una riunione. Inizierò spiegando lo scenario e chiederò a tutti se possono trovare il problema o vedere un problema, coinvolgerli. Fai in modo che tutti facciano domande. Quindi presentare finalmente un approccio migliore. Se qualcun altro ha un approccio migliore, li ringrazio e riconosco di fronte al team che il loro approccio è migliore. Questo dimostra che non sono il tipo di personalità "a modo mio o dell'autostrada". Inoltre, non apro MAI il lavoro di qualcuno e inizio a sottolineare i problemi in una riunione, l'autore non lo apprezzerà, indipendentemente da quanto sia bello e innocuo, penso di essere.
Quando faccio recensioni, non cerco solo un buon codice pulito ma anche ciò che il codice sta facendo. Se il requisito aziendale è: se un dipendente è stato con l'azienda per più di 10 anni, dare loro un aumento del 5%. Altrimenti, 2,5% . La prima cosa che controllo è se lo sta effettivamente facendo. Quindi controllo se lo sta facendo in modo pulito, coerente e performante.
Se faccio una recensione, mi assicuro di dare seguito o nessuno prenderà sul serio le recensioni.
Ho lavorato con qualcuno anni fa per fare una recensione e cc il responsabile dello sviluppo e il responsabile del controllo qualità ma entrambi i manager provenivano da un background aziendale o avevano poca esperienza di sviluppo. Lo ha fatto solo per impressionarli. A nessuno piaceva e fu allora che mi dissi che non avrei mai fatto quell'errore.
L'altra cosa che faceva era scegliere lo stile di programmazione ed era convinto che il suo stile fosse il migliore ("Il mio kungfu è molto meglio del tuo stile da scimmia ..."). Questa è stata un'altra lezione per me: esiste sempre più di un modo per risolvere un problema.
Rispondi ad alcune delle tue domande numerate
1- dovrei correggere il codice da solo?
No, vedere i motivi che ho indicato sopra.
2- dovrei dare loro feedback sul processo di revisione e lasciare che facciano le correzioni secondo le mie istruzioni?
Sì, prova a usare frasi e un tono amichevole ma che richiede attenzione. Sii il più chiaro possibile. Indica qual è il problema con il codice, come migliorarlo. NON chiedere semplicemente di cambiarlo. Ma fornire ragioni.
come posso dare questo feedback, riempire un determinato documento modello e inviarlo a loro, o c'è qualche software che mi aiuterà a contrassegnare le cose con problemi all'interno dei file di codice in cui potranno successivamente verificarlo? (Sto usando Visual Studio).
Come ho detto, puoi usare lo strumento che uso o un altro strumento. Non utilizzare documenti e-mail o word perché si perdono ed è difficile tenerne traccia.
Dopo aver eseguito la revisione del codice e le correzioni sono state completate, qualche volta è passato e alcune parti del codice che ho esaminato in passato sono cambiate, come posso fare il processo di riesame? dovrei ricontrollare tutto il codice da capo?
Principalmente quello che faccio è controllare il delta (solo modifiche). Ma devi avere in mente il quadro generale per assicurarti che nulla sia rotto e segua l'architettura.
Pensieri finali
Personalmente penso che la parola "revisione del codice" sia una cattiva scelta e non so come sia iniziata. Avrebbero potuto scegliere una parola molto migliore e meno autorevole.