Come rifiutare una revisione del codice che ritieni non necessaria?


89

Sono in una posizione in cui mi è stato chiesto di rivedere alcuni codici che risolvono un problema che non credo esista.

Il riparatore, che è più anziano di me, insiste sul fatto che la sua correzione è necessaria ma sembra non essere altro che sofisma del C ++ per me. Parte del nostro processo di distribuzione è una revisione del codice e, come secondo ingegnere più elevato in una piccola azienda, mi aspetto di rivedere le modifiche.

Ritengo che i revisori siano altrettanto responsabili delle modifiche al codice del programmatore originale e non sono disposto ad accettare la responsabilità di tale modifica. Come vorresti rifiutare questa recensione?


113
Mi sembra ovvio. Fai notare nella recensione che il codice è una masturbazione intellettuale in C ++ il cui scopo è quello di risolvere un problema che non esiste. E poi, come parte del processo di revisione, si rifiuta il codice.
user16764,

86
Non usare le parole "masturbazione intellettuale" quando la rifiuti. Se usi questa formulazione, lo contrasterai e non vedrà quello che hai da dire come una critica tecnica potenzialmente corretta, lo vedrà come un attacco personale. Potrebbe essere esattamente una masturbazione intellettuale, ma puoi essere assolutamente certo che non la vede così.
Michael Shaw,

15
James - Ho tolto l'emozione dalla tua domanda per consentire alla community di concentrarsi sulla tua domanda principale. Come altri sottolineano, l'uso della terminologia caricata nella tua recensione non farà che aggravare quella che è chiaramente una situazione delicata.

8
C e C ++ sono pieni di cose che sembrano funzionare ma in realtà sono comportamenti indefiniti. UB è un vero difetto, anche se non puoi scrivere un test che mostra che non funziona come dovrebbe. Ad esempio, molti compilatori usano UB come opportunità di ottimizzazione, supponendo che il caso indefinito non accada mai. Ad esempio, se si size > size+1verificava l'overflow di un numero intero con segno, il compilatore potrebbe semplicemente sostituire questa espressione con false, poiché l'overflow di numeri interi con segno non è definito. Vedi blog.llvm.org/2011/05/…
CodesInChaos

5
@MichaelShaw "lo vedrà come un attacco personale." che la formulazione della domanda mi sembra, un attacco personale a un dev più anziano con cui OP ha una differenza di opinione che ora può "vincere" perché è stato messo in una posizione di potere.
jwenting

Risposte:


274

Richiedi un caso di test che non ha esito positivo senza la modifica che ha esito positivo con la modifica.

Se non riesce a produrne uno, lo usi come giustificazione.

Se riesce a produrne uno, è necessario spiegare perché il test non è valido.


245
O forse se riesce a produrne uno, riesamini i tuoi presupposti e pensi che potrebbe essere stato giusto dopo tutto. Presumibilmente, il punto dell'esercizio è migliorare il codice, non vincere il dibattito.
Caleb,

99
Solo perché non puoi scrivere un test non significa che non sia rotto. Comportamento indefinito che di solito funziona come previsto (C e C ++ ne sono pieni), condizioni di gara, potenziale riordino a causa di un modello di memoria debole ...
CodesInChaos

29
Inoltre, che dire del refactoring standard? Come si scrive un test fallito per un lavoro di refactoring?
Mike Weller,

62
"Chiedigli di dimostrare perché è necessario ..." Forse chiedigli di insegnarti perché è necessario.
Mike Sherrill 'Cat Recall',

8
@RhysW: presupposto errato. Anche il codice esistente, con le condizioni di gara, non può essere verificato a tale riguardo. Quindi il nuovo codice è teoricamente migliore ed empiricamente equivalente. Il tuo presupposto è valido solo se il vecchio codice è empiricamente migliore.
Salterio

152

I revisori dovrebbero essere obiettivi.

È chiaro che hai già formulato un'opinione sul codice in questione prima ancora di averlo esaminato, e sembra che tu e il fixer abbiate delle posizioni. Se è così, allora avrai un momento difficile apparire obiettivo e un momento ancora più difficile essere obiettivi. Niente di tutto ciò aiuta il processo, e potrebbe essere che la cosa migliore e più obiettiva che puoi fare sia inchinarti perché sei troppo vicino al problema.

Prendi in considerazione un approccio di squadra.

Se non è possibile rimuoverti, è possibile che diversi altri ingegneri esaminino il codice contemporaneamente. O saranno d'accordo con te sul fatto che il codice debba essere rifiutato o non lo faranno. Se sono d'accordo con te, allora non sarai più solo tu contro il riparatore, e sarai in grado di fare un caso più forte in cui il team ha esaminato la correzione obiettivamente e ha deciso di non accettarla. D'altra parte, se decidono di accettare la correzione, anche quella sarà una decisione della squadra. Va da sé che dovresti partecipare con la mente più aperta che puoi e che non dovresti cercare di influenzare le opinioni degli altri membri del team con qualcosa di diverso dalla discussione razionale. Importante: in caso di esito negativo in seguito, non gettare la squadra sotto l'autobus dicendo "Beh, io diceva sempre che si trattava di un codice errato, ma ero in minoranza rispetto agli altri membri del team ".

I rifiuti sono una parte naturale del processo di revisione del codice.

Il processo di revisione del codice non è lì per le correzioni del timbro di gomma da parte di persone più anziane; è lì per proteggere e migliorare la qualità del codice. Non c'è nulla di sbagliato nel rifiutare una correzione, purché tu lo faccia per la giusta ragione, cioè che la correzione non migliora il codice. Se, dopo una revisione aperta del codice, ritieni ancora che la correzione non riduca il rischio e / o l'entità di un problema dimostrabile, allora dovresti rifiutarlo. Non è personale, solo la tua onesta opinione. Se il fixer non è d'accordo, va bene lo stesso, e a quel punto diventa un problema per la gestione capire. Assicurati di rimanere onesto, aperto e professionale.

La responsabilità taglia in entrambi i modi.

Hai detto che non vuoi essere responsabile di questo cambiamento, apparentemente perché non credi che ci sia un problema. Tuttavia, è necessario rendersi conto che se ti sbagli e non v'è un problema, allora si può finire per essere responsabile per respingere il codice che avrebbe evitato il problema.

Prendi nota.

Tenere un registro scritto del processo di revisione ti aiuterà a chiarire i fatti. Annota i tuoi pensieri e le preoccupazioni durante la revisione, la descrizione e i risultati di eventuali test che potresti eseguire per misurare il presunto problema e la correzione, ecc. Se il problema si intensifica, avrai una registrazione di ciò che hai fatto per supportare il tuo posizione. Se la questione si ripresenterà in futuro (probabilmente lo farà se il fissatore è attaccato alla sua stessa visione), avrai qualcosa per correre la tua memoria.


24
+1 questo è molto più utile della risposta accettata
Simon Bergot

2
Decisamente. La risposta accettata è specifica per un caso, chiaramente non così generale e ben ponderata come questa.
Florian Margaine,

40

Annota i motivi del rifiuto e le difese per possibili controproposte. Quindi discutere razionalmente con il riparatore e, se necessario, passare alla direzione.

Se hai una documentazione sufficiente (inclusi elenchi di codici, risultati dei test e argomenti oggettivi ), sarai ben coperto.

Provocherai una cattiva volontà con il riparatore, quindi assicurati che il problema valga la pena (cioè, il non risolto provoca danni?)

Inoltre, se il fixer è in qualche modo correlato ai proprietari, dimentica questa risposta.


9
Vorrei votare due volte solo per l'ultima parte della tua risposta. Risposta molto solida.

31

Di recente nelle notizie di LinkedIn, c'era un articolo sulla risoluzione dei conflitti sul posto di lavoro e sull'essere umili, piuttosto che apparire arroganti. Purtroppo, non riesco a trovare il collegamento ora, ma l'essenza generale era cercare di formulare domande in modo non conflittuale. Per favore, non prenderlo come me insinuando che sei arrogante, è solo il modo in cui l'articolo è stato scritto.

Ad ogni modo, nel dire al programmatore senior che ha torto nel suo presupposto, lo porterà solo ad adottare un approccio difensivo e ad attaccarti di nuovo nella sua risposta. Tuttavia, se poni la domanda sul perché crede che il problema esista, dal punto di vista della tua mancanza di comprensione, è probabile che sia più aperto a discutere della questione.

Quindi, piuttosto che dire "Il problema non esiste, quindi non dovrei rivedere questo", forse chiedere qualcosa del tipo "Per poterlo esaminare correttamente, devo capire il problema. Puoi spiegarlo per favore dal tuo punto di vista?"

Ad esempio, l'articolo descriveva un test dato ai bambini in cui un adulto sollevava un cubo le cui facce erano tutte di un colore, ad eccezione di quello rivolto verso l'adulto. Quando ai bambini veniva chiesto di che colore fosse il volto dell'adulto, quelli di età inferiore ai 5 anni dicevano quasi sempre il colore che potevano vedere, poiché non potevano capire che l'adulto poteva avere una visione diversa dalla propria.


8
Ottimo punto, ma non riesco a capire come sia correlato l'esempio in basso (non pretendo che sia indipendente, ovviamente, sottolineo la mia mancanza di comprensione della relazione).
ugoren,

8
@ugoren Ah ah, mi piace quello che hai fatto lì!
TheDarkKnight

1
@ugoren la relazione è 'a meno che tu non riesca a vedere l'intera immagine, non formare opinioni concrete'
RhysW

2
Mi piace sempre l'approccio umile, rifiuterei il cambiamento sulla base del fatto che non capisco e quindi non sono qualificato per dargli l'ok.
PhilDin,

2
@PhilDin C'è umile e poi c'è in giro dicendo che non sei qualificato per il lavoro. Se è in grado di rivedere il codice, penso che le persone che lo mettono in quella posizione si aspettano che sia abbastanza qualificato per farlo.
Andy,

9

C / C ++ può essere pieno di comportamenti indefiniti. Una mano è cattiva in quanto può portare a comportamenti imprevisti. D'altra parte consente un'ottimizzazione aggressiva e di solito quando si utilizza C / C ++ si è interessati alla velocità.

Scrivere un caso di prova che potrebbe rompersi, potrebbe comportare una strana architettura o un compilatore che non esiste più. Inoltre potrebbe sembrare come su qualsiasi architettura sensibile "non dovrebbe causare alcun problema".

Tuttavia, in un momento o nell'altro, cambierai piattaforma (diciamo: vuoi andare su mobile in modo da portarti su ARM o vuoi velocizzare le cose e usare la GPU). A questo punto le cose potrebbero iniziare a rompersi e dovrai eseguirne il debug. Potrebbe essere banale come aggiornare il compilatore alla versione più recente (e potresti volerlo / averne bisogno).

Il codice problematico era:

int d[16];

int SATD (void)
{
   int satd = 0, dd, k;
   for (dd=d[k=0]; k<16; dd=d[++k]) {
     satd += (dd < 0 ? -dd : dd);
   }
   return satd;
 }

Durante l'ultima iterazione d[++k] => d[++15] => d[16]si accede. Poiché di solito l'elemento successivo era la memoria legale (in termini di paging non modello di memoria C), anche i banali compilatori non producevano alcun eseguibile con un comportamento strano. L'unico modo per scrivere il test case era trovare una piattaforma con esattamente lo stesso modello di memoria di C (probabilmente VM).

Comunque gcc 4.8 prima di tutto visto che d[++k]viene eseguito in ogni ciclo. Quindi, k < 16altrimenti l'accesso sarebbe illegale e la legalità del programma inviato al compilatore è parte del contratto. Quindi la condizione del loop è sempre vera, dati i presupposti, quindi è loop infinito. Questo potrebbe sembrare strano ma era un'ottimizzazione perfettamente legale - l'emissione system("dd if=/dev/zero of=/dev/sda"); system("format c:")sarebbe anche la corretta sostituzione del loop. Ci sono modi più sottili in cui puoi scegliere di esibire comportamenti. Ad esempio, durante una lezione sulla memoria transazionale, ricordo che il presentatore ha provato più volte a ottenere un valore errato quando 2 thread hanno incrementato lo stesso valore.

Tuttavia C / C ++, al contrario di alcune lingue, è standardizzato in modo tale controversia può essere fatta con riferimento alla fonte obiettiva:

  • Se ritieni che questo non sia un problema, prova a dimostrarlo utilizzando lo standard C / C ++ (ovvero che porta a valore e comportamento definiti)
  • Se pensa che questo sia un problema, chiedigli di dimostrarlo usando lo standard C / C ++ (cioè che porta a valore o comportamento indefiniti)

In generale, se il tuo team sta scrivendo in C / C ++ è utile avere a portata di mano lo standard - anche gli esperti del team possono trovare qualcosa di strano lì ogni tanto.


4

Sembra più un problema con la politica del tuo team che con questa recensione specifica. Quando lavoravo in un grande negozio di software in una squadra di 9 persone, un critico di recensioni aveva il potere di veto sul codice, e questo era uno standard che tutti rispettavamo. Eravamo abbastanza talentuosi e esperti - vale a dire. "maturo", ma più nel senso di "non infantile" che di "stagionato" - che il nostro team leader potrebbe ragionevolmente aspettarsi che saremo sempre in grado di raggiungere un accordo senza trasformarci in discussioni in un periodo di tempo prudente.

Semplicemente in base alla tua lingua nel tuo post, potrei avvertirti che sembra che ti avvicinerai a questa situazione in un modo che potrebbe portare a una discussione devoluta. Forse è "la masturbazione intellettuale", ma probabilmente c'è una ragione per cui l'ha fatto, e l'onere per te sarà quello di trovare un modo più semplice per risolvere quel problema - e se non esiste tale modo, documenta nei commenti perché il codice masturbatorio era, infatti, necessario.


1
"... ma probabilmente c'è una ragione per cui lo ha fatto ..." - È un grande presupposto che stai facendo. E ti manca anche il punto che la domanda afferma che (secondo l'opinione del PO) non esiste alcun problema. Certamente, l'onere dovrebbe essere sulla persona che sta proponendo una "correzione" per dimostrare che esiste un problema reale da risolvere. Non ha senso proporre una "soluzione più semplice" a un problema che non esiste.
Stephen C

4
@StephenC sì, e sono d'accordo con l'opinione che l'OP dovrebbe dare il beneficio del dubbio in questo caso. Altrimenti sarà una recensione davvero conflittuale.
Djechlin,

3

Fai in modo che il mittente mostri che il suo codice risolve il suo problema. Se può testare e mostrarti le prove, allora sei tu quello che ha torto e dovrebbe semplicemente smettere di lamentarti e affrontarlo. Se non è in grado di mostrare le prove a supporto della sua richiesta, c'è un problema e mostrare la prova che la sua patch risolve il problema, quindi lo rimanderei al tavolo da disegno.

Naturalmente ci potrebbe essere una politica interna delicata attorno a questo. Ma questo è il modo in cui andrei (delizioso).

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.