È utile rivedere i programmi con gli anziani e il capo anche se funziona bene?

Nella mia azienda, prima della consegna di qualsiasi progetto, il mio capo chiede ai miei anziani di rivedere i programmi scritti da me o da altri membri del team o, talvolta, il capo si siede anche con noi per la revisione.

Penso che sia un buon modo per acquisire conoscenza, ma a volte quando i programmi funzionano bene, non funzionano allo stesso modo dopo la revisione e devo rivedere il mio programma.

Dicono che la revisione aiuta a ottimizzare l'esecuzione del programma e delle query, ma possiamo preferire l'ottimizzazione rispetto all'effettivo funzionamento del programma?

— Himanshu
fonte

come puoi essere sicuro che funzioni bene senza revisione da parte di qualcuno che non conosce le idiosincrasie a cui sei abituato quando fai i tuoi test

— maniaco del cricchetto

perché rivedono il codice dopo il test completo del modulo da parte del team di test.

— Himanshu,

@Himanshu: la revisione dopo il test è decisamente troppo tardi . Le revisioni devono essere eseguite sui lavori in corso.

— Jan Hudec,

Abbraccia questa pratica. Vorrei disperatamente che lo stessimo facendo nei miei team. Aiuta a eliminare i silos di conoscenza (un grosso problema per noi) e garantisce che i tuoi compagni di squadra possano lavorare con il tuo codice. Se le tue recensioni indicano che il tuo codice viene riscritto a volte, è una buona cosa. Anche i grandi programmatori a volte scrivono codice errato; alcuni di noi vorrebbero più tempo per tornare indietro e ripulirlo. Questa dovrebbe essere l'occasione per avere una grande esperienza di apprendimento con persone più esperte di te. Non prenderlo come persone che attaccano il tuo codice; prendilo come gente che cerca di aiutarti a farti diventare un programmatore più esperto.

— jpmc26,

Se è comune che il codice che "funziona bene" venga fatto a pezzi durante la revisione del codice nella misura in cui i membri del team ritengono che si stia perdendo molto slancio, allora dovresti forse considerare la programmazione di coppia, quindi il codice viene rivisto mentre viene scritto.

— Buhb,

Risposte:

"Lavorare bene" è davvero una grande metrica, ma se sei l'unico nel team in grado di decifrare ciò che hai scritto, e quindi mantenerlo, il codice è quasi inutile per l'azienda a medio o lungo termine.

Un buon codice è almeno:

funziona come previsto
leggibile / chiaro
facilmente manutenibile
facilmente estensibile per futuri cambiamenti
sicuro
senza dipendenze non necessarie
gestire correttamente i casi non nominali
eccetera

(Alcuni di questi requisiti sono in realtà sovrapposti ma sono buoni da considerare individualmente ...)

Le revisioni del codice servono allo scopo oltre la parte "funzionante", che può essere eseguita tramite test automatici.

Personalmente so che questo è fastidioso avere qualcosa che sta venendo distrutto e doverlo ricostruire da zero. Ma, spesso, ciò è dovuto a una cattiva comunicazione da parte del senior / tech lead. Quindi, se pensi di dover riscrivere troppo spesso, la prossima volta, vai al revisore prima di scrivere una sola riga e cerca di ottenere quante più informazioni possibili su ciò che si aspetta, in ogni dettaglio. Potrebbe anche essere fantastico se il team di revisori del codice riassuma le loro aspettative in un documento formale a cui ogni sviluppatore può fare riferimento.

Da un lato più positivo, una sessione potrebbe anche essere un'occasione per condividere grandi pratiche / progetti.

— Xavier T.
fonte

Aggiungerei che testare il codice non implica l'assenza di bug, ad esempio i casi limite in cui il software si arresterebbe in modo anomalo.

— coloranti

Sono d'accordo, e anche i test automatici dovrebbero essere sottoposti a revisione del codice per essere sicuri che stiano testando la cosa giusta ... Tartarughe fino in fondo.

— Xavier T.

Ho interpretato la tua domanda come "Il mio codice funzionante può essere macellato in una recensione fino a un punto in cui non si compila più?" .

Sì, può. Generalmente, durante una revisione, guardi come il tuo codice fa quello che fa. Quando vuoi consegnare il tuo codice, dici di aver finito una certa parte del programma.

Dici che funziona. Il test viene quindi eseguito per verificarlo. Un modulo che supera i test non significa che il modulo non debba essere toccato di nuovo.

Un modulo che appare funzionale può ancora essere un disastro in attesa che accada, sia in fase di esecuzione o in pochi mesi quando tu o qualcun altro deve eseguire la manutenzione su di esso. Modificando il codice in una recensione e sottolineando ciò che non andava, il tuo revisore (si spera) sta cercando di insegnarti effettivamente qualcosa.

— CodeCaster
fonte

Le peer review sono senza dubbio un ottimo modo di apprendere. Qualcuno potrebbe vedere qualcosa di diverso, avere un'esperienza diversa per te e dovrebbe essere in grado di contribuire al miglioramento. Questo non dovrebbe essere denigratorio, mi aspetto che qualsiasi sviluppatore possa commentare e criticare in modo costruttivo il codice di chiunque!

Mi sembra che alcuni di questi "miglioramenti" stiano effettivamente apportando modifiche sostanziali perché (come prevedibile) lo sviluppatore che ha recensito ha meno esperienza con il software dell'autore.

Questa tendenza è il feedback personale, forse il tuo codice è difficile da seguire o mantenere? Le tue recensioni sono preziose? Assolutamente! Posso vedere come può essere frustrante, avere un codice funzionante che i tuoi colleghi sembrano rompere, non dovresti essere scoraggiato - dovresti lavorare per proteggere il tuo codice da questi cambiamenti.

La domanda diventa quindi come proteggere la funzionalità dei programmi in modo da sapere che la funzionalità funziona ancora dopo aver completato le recensioni. Il mio suggerimento sarebbe di assicurarti una copertura decente per i test unitari. In questo modo ogni volta che tu / il tuo revisore / il vostro successore modificate il codice, possono essere certi che le modifiche apportate sono sicure.

ETA: Ho appena individuato uno dei tuoi commenti, sono sicuro che questo è ovvio, ma le revisioni del codice dovrebbero essere fatte prima che il team di test ci metta le mani sopra. Altrimenti non stanno testando il prodotto finale.

— Liath
fonte

I test di integrazione sono anche estremamente utili per rilevare rotture.

— jpmc26,