Come rifiutare una revisione del codice che ritieni non necessaria?

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?

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.

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.

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.

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.

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.

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.

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).