Nelle revisioni del codice, il revisore deve sempre presentare una soluzione ai problemi? [chiuso]

Durante la revisione del codice, di solito provo a formulare raccomandazioni specifiche su come risolvere i problemi. Ma a causa del tempo limitato che si può dedicare alla revisione, questo non sempre funziona bene. In questi casi lo trovo più efficiente se lo sviluppatore trova una soluzione da solo.

Oggi ho rivisto un po 'di codice e ho scoperto che una classe ovviamente non era ben progettata. Aveva un numero di attributi opzionali che sono stati assegnati solo per determinati oggetti e lasciati vuoti per altri. Il modo standard per risolvere questo sarebbe quello di dividere la classe e utilizzare l'ereditarietà. Tuttavia, in questo caso specifico, questa soluzione sembrava complicare eccessivamente le cose. Non sono stato coinvolto nello sviluppo di questo software da solo e non ho familiarità con tutti i moduli. Pertanto non mi sono sentito abbastanza informato per prendere una decisione specifica.

Un altro caso tipico che ho riscontrato molte volte è che trovo una funzione, un nome di classe o una variabile ovviamente insignificante o addirittura fuorviante, ma non riesco a trovare un buon nome da solo.

Quindi in generale, come revisore, va bene dire "questo codice è difettoso perché ... fallo diversamente" o devi trovare una soluzione specifica?

Come revisore, il tuo compito è verificare se un pezzo di codice (o un documento) soddisfa determinati obiettivi che sono stati concordati prima della revisione.

Alcuni di questi obiettivi implicheranno in genere una decisione di giudizio se l'obiettivo è stato raggiunto o meno. Ad esempio, l'obiettivo che il codice deve essere mantenibile richiede in genere un giudizio.

Come revisore, è tuo compito sottolineare dove gli obiettivi non sono stati raggiunti ed è compito dell'autore assicurarsi che il suo lavoro effettivamente raggiunga gli obiettivi. In questo modo, non è compito tuo dire come devono essere fatte le correzioni.

D'altra parte, solo dire all'autore "questo è difettoso. Risolvilo" di solito non porta a un'atmosfera positiva nella squadra. Per un'atmosfera positiva, è bene almeno indicare perché qualcosa è difettoso nei tuoi occhi e fornire un'alternativa migliore se ne hai una.
Oltre a ciò, se stai recensendo qualcosa che sembra "sbagliato" ma non hai davvero un'alternativa migliore, allora potresti anche lasciare un commento sulla falsariga di "Questo codice / design non mi sta bene, ma io non ho una chiara alternativa. Possiamo discuterne? " e poi prova a ottenere qualcosa di meglio insieme.

Alcune buone risposte qui, ma penso che manchi un punto importante. Fa una grande differenza di cui stai esaminando il codice, quanto esperienza ha quella persona e come gestisce tali suggerimenti. Se conosci bene il tuo compagno di squadra e ti aspetti che una nota del tipo "questo codice sia difettoso perché ... fallo diversamente" per essere sufficiente a trovare una soluzione migliore, allora un commento del genere può andare bene. Ma ci sono sicuramente persone in cui un tale commento non è sufficiente e che hanno bisogno di sapere esattamente come migliorare il loro codice. Quindi IMHO questa è una sentenza che puoi fare solo per il singolo caso.

Quindi in generale, come revisore, va bene dire "questo codice è difettoso, fallo diversamente" o devi trovare una soluzione specifica?

Nessuno dei due è l'IMO ideale. La cosa migliore da fare è parlare con l'autore e risolvere il problema in modo collaborativo.

Le recensioni del codice non devono essere asincrone. Un sacco di problemi si sbloccheranno se smetti di vederli come un processo burocratico e impieghi un po 'di tempo per la comunicazione dal vivo.

Nelle revisioni del codice, il revisore deve sempre presentare una soluzione ai problemi?

No. Se lo fai, non sei un recensore, sei il prossimo programmatore.

Nelle revisioni del codice, il revisore non dovrebbe mai presentare una soluzione ai problemi?

No. Il tuo compito è comunicare il problema in questione. Se presentare una soluzione chiarisce il problema, fallo. Non aspettarti che segua la tua soluzione. L'unica cosa che puoi fare qui è prendere un punto. Non puoi dettare l'implementazione.

Quando un revisore dovrebbe presentare una soluzione ai problemi?

Quando questo è il modo più efficace per comunicare. Siamo scimmie in codice e non in inglese. A volte il modo migliore per mostrare che il codice fa schifo ... è meno che ottimale ... è mostrare loro il codice che fa schifo meno ... è più opt ... oh diavolo sai cosa intendo.

Il problema principale è che se le persone sapessero come scrivere meglio il codice, di solito lo avrebbero fatto in primo luogo. Se una critica è abbastanza specifica dipende molto dall'esperienza dell'autore. I programmatori molto esperti potrebbero essere in grado di prendere una critica come "questa classe è troppo complicata" e tornare al tavolo da disegno e trovare qualcosa di meglio, perché avevano solo una giornata libera a causa di un mal di testa o erano sciatti perché erano di fretta.

Di solito, però, devi almeno identificare la fonte della complicazione. "Questa classe è troppo complicata perché infrange la Legge di Demetra dappertutto." "Questa classe mescola le responsabilità del livello di presentazione e del livello di persistenza." Imparare a identificare quei motivi e spiegarli in modo succinto fa parte del diventare un recensore migliore. Raramente devi entrare in molti dettagli sulle soluzioni.

Esistono due tipi di programmatori errati: quelli che non seguono le pratiche standard e quelli che "solo" seguono le pratiche standard.

Quando ho avuto un contatto limitato con il lavoro / fornendo feedback a qualcuno, non avrei detto "Questo è un cattivo design". ma qualcosa del tipo "Puoi spiegarmi questa lezione?" Potresti scoprire che è una buona soluzione, lo sviluppatore ha fatto sinceramente il meglio che poteva o addirittura ha riconosciuto che è una cattiva soluzione, ma è abbastanza buona.

A seconda della risposta, avrai un'idea migliore su come affrontare ogni situazione e persona. Possono riconoscere rapidamente il problema e scoprire la correzione da soli. Potrebbero chiedere aiuto o tenteranno semplicemente di risolverli da soli.

Ci sono pratiche suggerite nella nostra attività, ma quasi tutte hanno delle eccezioni. Se capisci il progetto e come il team si sta avvicinando, questo può essere il contesto per determinare lo scopo della revisione del codice e come affrontare le preoccupazioni.

Mi rendo conto che questo è più un approccio al problema che una soluzione esplicita. Ci sarà troppa variabilità per coprire tutte le situazioni.

Quando rivedo il codice fornisco solo una soluzione per i problemi che identifico se riesco a farlo con poco sforzo. Cerco di essere specifico su ciò che penso sia il problema, facendo riferimento, ove possibile, alla documentazione esistente. Aspettarsi che un revisore fornisca una soluzione per ogni problema identificato crea un incentivo perverso - scoraggerà il revisore dal sottolineare i problemi.

La mia opinione sta andando più forte nel non fornire codice nella maggior parte dei casi, per una serie di motivi:

• Se la spiegazione da sola non è sufficiente, possono sempre chiedere un campione di ciò a cui stai pensando.
• Non stai perdendo tempo cercando di acquisire familiarità con un codice che non hai toccato da molto tempo, solo per modificarlo leggermente, mentre qualcun altro ha appena trascorso il proprio tempo a fare proprio questo.
• Se hanno già familiarità con il pezzo di codice e non lo sei, dare solo il feedback potrebbe comportare un codice migliore di quello che potresti scrivere. Dare a qualcuno una soluzione pronta spesso lo farà semplicemente usare, senza considerare di migliorarlo ulteriormente.
• Fornire sempre una soluzione è al limite della condiscendenza. Stai lavorando con qualcuno, si spera perché erano abbastanza buoni per essere assunti. Se sei riuscito a capire perché qualcosa è una cattiva idea, perché non dovrebbero impararla ascoltando il feedback e facendolo da soli?
• Fornire sempre una soluzione è semplicemente strano. Immagina di accoppiare la programmazione alla loro scrivania: hanno appena finito un paio di righe che pensi non siano grandi. Dite semplicemente loro cosa avete notato e perché, o prendete la loro tastiera e mostrate immediatamente la vostra versione? Questo è ciò che può sempre fornire la tua soluzione alle altre persone.
• Puoi sempre dire quello che faresti invece, senza spendere il tempo per scriverlo davvero. Lo hai fatto solo descrivendo il primo problema nella domanda.
• Non distribuire cibo, insegnare a pescare;)

Certo, ci sono alcuni casi in cui stai pensando a qualche alternativa specifica, e vale la pena attaccarlo. Ma è davvero raro nella mia esperienza. (molte recensioni, grandi progetti) L'autore originale può sempre chiederti un campione, se necessario.

Anche allora, a causa del terzo motivo, quando si dà un campione può valere la pena di dire, ad esempio, "l'uso x.foo()renderebbe questo più semplice" piuttosto che una soluzione completa - e lasciare che l'autore lo scriva. Ciò consente anche di risparmiare tempo.

Penso che la chiave per la revisione del codice sia quella di concordare le regole prima della revisione.

Se hai un chiaro insieme di regole, non dovrebbe essere necessario offrire una soluzione. Stai solo verificando che le regole siano state seguite.

L'unica volta che sorgerebbe la domanda di un supplente sarebbe se lo sviluppatore originale non potesse pensare a un modo per implementare la funzionalità che si adatta alle regole. Supponi di avere un requisito di prestazioni, ma la funzionalità richiede più tempo della soglia dopo diversi tentativi di ottimizzazione.

Però! se le tue regole sono soggettive "I nomi devono essere approvati da me!" quindi sì, ti sei appena nominato namer in capo e dovresti aspettarti richieste di elenchi di nomi accettabili.

Il tuo esempio di ereditarietà (parametri opzionali) è forse migliore, nel senso che ho visto regole di revisione del codice che proibiscono metodi lunghi e "troppi" parametri di funzione. Ma normalmente questi possono essere banalmente risolti dividendo. È la parte "questa soluzione sembrava complicare troppo le cose" in cui la tua obiettività è intrusiva e forse richiede una giustificazione o una soluzione alternativa.

Se una potenziale soluzione è semplice e veloce da scrivere, provo a includerla nei miei commenti di peer review. In caso contrario, elencherò almeno la mia preoccupazione e perché trovo problematico quel particolare articolo. Nel caso di nomi di variabili / funzioni in cui non riesci a pensare a qualcosa di meglio, di solito, riconosco di non avere un'idea migliore e finisco il commento sotto forma di una domanda aperta nel caso in cui qualcuno possa . In questo modo se nessuno si presenta con un'opzione migliore, la recensione non viene realmente trattenuta.

Per l'esempio che hai dato alla tua domanda, con la classe mal progettata. Vorrei lasciare alcuni commenti sul fatto che sebbene possa sembrare eccessivo, l'ereditarietà sarebbe probabilmente il modo migliore per affrontare il problema che il codice sta cercando di risolvere, e lasciarlo a quello. Vorrei provare a formulare una frase che indichi che non è un ostacolo allo spettacolo e dipende dalla discrezione dello sviluppatore se risolvere o meno. Vorrei anche aprire con il riconoscimento che non hai familiarità con quella parte del codice e invitare sviluppatori e / o revisori più informati a chiarire se c'è una ragione per cui è andata così.

Vai e parla con la persona di cui stai recensendo il codice. Di 'loro, in modo amichevole, che hai trovato un po' difficile da capire, e poi discuti con loro su come potrebbe essere chiarito.

La comunicazione scritta porta a enormi quantità di tempo sprecato, nonché a risentimento e incomprensioni.

Faccia a faccia, la larghezza di banda è molto più elevata e si ha il canale emotivo laterale per prevenire l'ostilità.

Se in realtà parli con il ragazzo, è molto più veloce e potresti fare nuove amicizie e scoprire che entrambi apprezzerai di più il tuo lavoro.