Come gestisco il disaccordo in una revisione del codice riguardo a un caso limite improbabile?

Sto lavorando a una startup di robotica in un team di copertura del percorso e dopo aver inviato una richiesta pull, il mio codice viene esaminato.

Il mio compagno di squadra, che fa parte della squadra da più di un anno, ha fatto alcuni commenti al mio codice che suggeriscono che faccio molto più lavoro di quanto ritenga necessario. No, non sono uno sviluppatore pigro. Adoro il codice elegante che ha buoni commenti, nomi di variabili, rientri e gestisce correttamente i casi. Tuttavia, ha in mente un diverso tipo di organizzazione con cui non sono d'accordo.

Fornirò un esempio:

Avevo passato una giornata a scrivere casi di test per passare a un algoritmo di ricerca della transizione che avevo realizzato. Mi aveva suggerito di gestire un caso oscuro che è estremamente improbabile che accada - in effetti non sono sicuro che sia possibile che accada. Il codice che ho creato funziona già in tutti i nostri casi di test originali e in alcuni nuovi che ho trovato. Il codice che ho creato supera già le nostre oltre 300 simulazioni eseguite di notte. Tuttavia, per gestire questo caso oscuro mi occorrerebbero 13 ore che potrebbero essere impiegate meglio nel tentativo di migliorare le prestazioni del robot. Per essere chiari, il precedente algoritmo che avevamo usato fino ad ora non ha gestito questo caso oscuro e non una volta, nei rapporti 40k che sono stati generati, si è mai verificato. Siamo una startup e dobbiamo sviluppare il prodotto.

Non ho mai avuto una revisione del codice prima e non sono sicuro di essere troppo polemico; dovrei solo stare zitto e fare quello che dice? Ho deciso di tenere la testa bassa e di apportare il cambiamento, anche se sono fortemente in disaccordo sul fatto che fosse un buon uso del tempo.

Rispetto il mio collega e lo riconosco come un programmatore intelligente. Sono solo in disaccordo con lui su un punto e non so come gestire il disaccordo in una revisione del codice.

Ritengo che la risposta che ho scelto soddisfi questi criteri per spiegare come uno sviluppatore junior può gestire il disaccordo in una revisione del codice.

un caso oscuro che è estremamente improbabile che accada - in effetti non sono sicuro che sia persino possibile accadere

Non avere comportamenti non testati nel codice può essere molto importante. Se viene eseguito un pezzo di codice, ad esempio 50 volte al secondo, si verificherà una probabilità su un milione ogni 5,5 ore circa di tempo di esecuzione. (Nel tuo caso, le probabilità sembrano inferiori.)

Puoi parlare delle priorità con il tuo manager (o chiunque sia una persona più anziana responsabile dell'unità in cui lavori). Capirai meglio se, ad esempio, lavorare sulla prestazione del codice o se il codice è a prova di proiettile è la priorità assoluta e quanto improbabile possa essere quel caso d'angolo. Il tuo revisore potrebbe anche avere un'idea distorta delle priorità. Dopo aver parlato con la persona responsabile, avrai un tempo più facile (dis) concordando con i suggerimenti dei tuoi revisori e avrai qualcosa a cui fare riferimento.

È sempre una buona idea avere più di un recensore. Se il tuo codice viene esaminato da un solo collega, chiedi a qualcun altro che conosce quel codice, o la base di codice in generale, di dare un'occhiata. Un secondo parere, ancora una volta, ti aiuterà a concordare più facilmente (dis) i suggerimenti del revisore.

Avere un numero di commenti ricorrenti durante diverse revisioni del codice di solito indica che una cosa più grande non viene comunicata chiaramente e gli stessi problemi sorgono ancora e ancora. Prova a scoprire quella cosa più grande e discuterne direttamente con il recensore. Poni abbastanza perché domande. Mi ha aiutato molto quando ho iniziato la pratica delle revisioni del codice.

Posso darti un esempio di un caso angolare che non potrebbe mai accadere che ha causato un disastro.

Durante lo sviluppo di Ariane 4, i valori degli accelerometri laterali sono stati ridimensionati per adattarsi a un numero intero con segno a 16 bit e poiché il massimo output possibile degli accelerometri, se ridimensionato, non potrebbe mai superare il 32767 e il minimo non potrebbe mai scendere al di sotto - 32768 non è stato necessario "verificare il sovraccarico del controllo della portata". In generale, tutti gli input dovrebbero essere controllati dal range prima di qualsiasi conversione, ma in questo caso ciò proverebbe a rilevare un caso d'angolo impossibile.

Diversi anni dopo fu sviluppato Ariane 5 e il codice per ridimensionare gli accelerometri laterali fu riutilizzato con test minimi in quanto "provato in uso". Sfortunatamente il razzo più grande potrebbe aspettarsi maggiori accelerazioni laterali, quindi gli accelerometri sono stati aggiornati e potrebbero produrre valori float a 64 bit più grandi .

Questi valori più grandi "racchiusi" nel codice di conversione, non ricordano alcun controllo dell'intervallo e i risultati al primo lancio nel 1996 non erano buoni. È costato milioni alla società e ha causato una grande pausa nel programma.

Il punto che sto cercando di chiarire è che non dovresti ignorare i casi di test come mai accaduti, estremamente improbabili, ecc .: gli standard che stavano codificando richiedevano il controllo della gamma di tutti i valori di input esterni. Se ciò fosse stato testato e gestito, il disastro avrebbe potuto essere evitato.

Si noti che in Ariane 4 non si trattava di un bug (poiché tutto funzionava bene per ogni possibile valore) - era un mancato rispetto degli standard. Quando il codice è stato riutilizzato in uno scenario diverso, ha fallito in modo catastrofico, mentre se l'intervallo di valori fosse stato troncato, avrebbe probabilmente fallito con garbo e l'esistenza di un test case per questo avrebbe potuto innescare una revisione dei valori. Vale anche la pena notare che, mentre i programmatori e i tester hanno ricevuto alcune critiche dagli investigatori a seguito dell'esplosione, la gestione, il controllo qualità e la leadership sono stati lasciati con la maggior parte della colpa.

Una precisazione

Sebbene non tutti i software siano critici per la sicurezza, né così spettacolari quando falliscono, la mia intenzione era quella di evidenziare che i test "impossibili" possono ancora avere valore. Questo è il caso più drammatico che io conosca, ma la robotica può anche produrre alcuni risultati disastrosi.

Personalmente, direi che una volta che qualcuno ha messo in evidenza un caso limite per il team di test, dovrebbe essere messo in atto un test per verificarlo. Il responsabile del team di implementazione o il project manager può decidere di non tentare di risolvere eventuali guasti rilevati, ma deve essere consapevole dell'esistenza di eventuali carenze. In alternativa, se il test è troppo complesso o costoso da implementare, può essere sollevato un problema in qualunque tracker sia in uso e / o nel registro dei rischi per chiarire che si tratta di un caso non testato - potrebbe essere necessario affrontarlo prima di un cambio di utilizzo o impedire un uso inappropriato.

Dal momento che non è stato gestito prima, è fuori portata per i tuoi sforzi. Tu o il tuo collega potete chiedere al vostro responsabile se vale la pena occuparsi di questo caso.

Con algoritmi complessi, è molto difficile provare che hai pensato a ogni caso di test che verrà fuori nel mondo reale. Quando lasci intenzionalmente un caso di test rotto perché non si presenterà nel mondo reale, potenzialmente stai lasciando altri casi di test che non hai ancora pensato.

L'altro effetto che si verifica spesso è quando si gestiscono ulteriori casi di test, l'algoritmo diventa necessariamente più generale e per questo motivo si trovano modi per semplificarlo e renderlo più robusto per tutti i casi di test. Ciò consente di risparmiare tempo nella manutenzione e nella risoluzione dei problemi lungo la strada.

Inoltre, ci sono innumerevoli casi di bug "questo non dovrebbe mai accadere" in natura. Questo perché l'algoritmo potrebbe non cambiare, ma i suoi input potrebbero cambiare anni lungo la strada quando nessuno si ricorda di questo caso d'uso non gestito. Ecco perché gli sviluppatori esperti gestiscono questo genere di cose quando sono freschi nelle loro menti. Se non lo fai, torna a morderti più tardi.

Questa non è una domanda tecnica ma una decisione di strategia aziendale. Notate che la soluzione suggerita è per un caso molto oscuro che non accadrà quasi mai. Qui fa una grande differenza se stai programmando un giocattolo o se stai programmando diciamo attrezzature mediche o un drone armato. Le conseguenze di un raro malfunzionamento saranno molto diverse.

Quando si eseguono revisioni del codice, è necessario applicare una comprensione di base delle priorità aziendali quando si decide quanto investire nella gestione di casi rari. Se non sei d'accordo con il tuo collega nella tua interpretazione delle priorità dell'azienda, potresti voler discutere con qualcuno sul lato commerciale delle cose.

Le revisioni del codice non riguardano esclusivamente la correttezza del codice. In realtà, questo è abbastanza lontano dall'elenco dei benefici, dietro la condivisione delle conoscenze e l'essere un processo lento ma costante verso la creazione di uno stile di squadra / consenso sul design.

Come stai vivendo, ciò che conta come "corretto" è spesso discutibile, e ognuno ha il proprio punto di vista su ciò che è. Nella mia esperienza, il tempo limitato e l'attenzione possono anche rendere le recensioni di codice altamente incoerenti: lo stesso problema potrebbe essere sollevato o meno a seconda di sviluppatori diversi e in momenti diversi dallo stesso sviluppatore. Revisori nella mentalità di "cosa migliorerebbe questo codice?" suggerirà spesso cambiamenti che non aggiungerebbero naturalmente ai propri sforzi.

Come programmatore esperto (più di 15 anni come sviluppatore), sono spesso recensito da programmatori con meno anni di esperienza rispetto a me. A volte mi chiedono cambiamenti con cui non sono d'accordo o che ritengo poco importante. Tuttavia, apporto ancora queste modifiche. Combatto battaglie sui cambiamenti solo quando ritengo che il risultato finale provocherebbe una debolezza del prodotto, in cui il costo del tempo è molto elevato o in cui un punto di vista "corretto" può essere reso obiettivo (ad esempio, la modifica richiesta per aver vinto ' lavorare nella lingua che stiamo usando, o un benchmark mostra che un miglioramento delle prestazioni dichiarato non è uno).

Quindi suggerisco di scegliere attentamente le tue battaglie. Due giorni per codificare un caso di prova che ritieni non sia necessario non vale probabilmente il tempo / lo sforzo per combattere. Se stai utilizzando uno strumento di revisione, come le richieste pull di GitHub, forse potresti commentare lì sui costi / benefici che percepisci, al fine di notare la tua obiezione, ma accetti di fare ancora il lavoro. Questo conta come un leggero respingimento, quindi il revisore sa che sta colpendo un limite e, cosa più importante, include la tua logica in modo che casi come questo possano essere intensificati se entrano in un punto morto. Vuoi evitare l'escalation delle divergenze scritte - non vuoi avere un argomento in stile forum su Internet sulle differenze di lavoro - quindi potrebbe essere utile discutere prima il problema e registrare un giusto sommario dell'esito della discussione,la discussione amichevole deciderà comunque per entrambi).

Dopo l'evento, questo è un buon argomento per la revisione dello sprint o le riunioni di pianificazione del team di sviluppo, ecc. Presentalo nel modo più neutro che puoi ad es. "Nella revisione del codice, lo sviluppatore A ha identificato questo ulteriore test, ci sono voluti altri due giorni per scrivere, no il team pensa che la copertura extra fosse giustificata a questo costo? " - questo approccio funziona molto meglio se effettivamente fai il lavoro, poiché ti mostra in una luce positiva; hai svolto il lavoro e desideri semplicemente sondare il team per avversione al rischio e sviluppo di funzionalità.

Ti consiglierei di asserire almeno contro il caso oscuro. In questo modo, non solo i futuri sviluppatori vedranno che hai deciso attivamente contro il caso, ma con una buona gestione degli errori, che dovrebbe già essere a posto, questo catturerebbe anche sorprese.

E poi, crea un caso di prova che asserisce tale fallimento. In questo modo, il comportamento è meglio documentato e verrà mostrato nei test unitari.

Questa risposta presuppone ovviamente che il tuo giudizio sull'essere "estremamente improbabile se possibile" sia corretto e non possiamo giudicarlo. Ma se lo è, e il tuo collega è d'accordo, allora un'affermazione esplicita contro l'evento dovrebbe essere una soluzione soddisfacente per entrambi.

Dal momento che sembri essere nuovo lì, c'è solo una cosa che puoi fare: verificare con il capo squadra (o capo progetto). 13 ore è una decisione aziendale; per alcune aziende / team, molto; per alcuni, niente. Non è una tua decisione, non ancora.

Se il lead dice "cover that case", va bene; se dice "nah, fanculo", bene - la sua decisione, la sua responsabilità.

Per quanto riguarda le recensioni di codice in generale, rilassati. Avere un'attività che ti viene restituita una o due volte è perfettamente normale.

Una cosa che non credo di aver visto indirizzata in natura, sebbene sia stata in qualche modo sollevata nella risposta di @SteveBarnes:

Quali sono le ripercussioni di un fallimento?

In alcuni campi un errore è un errore in una pagina Web. A PC schermate blu e riavvii.

In altri campi è la vita o la morte - l'auto a guida autonoma si blocca. Il pacemaker medico smette di funzionare. O nella risposta di Steve: le cose esplodono con conseguente perdita di milioni di dollari.

C'è un mondo di differenza in quegli estremi.

Se valga la pena o meno 13 ore per coprire un "fallimento", non dovrebbe dipendere da te. Dovrebbe spettare alla direzione e ai proprietari. Dovrebbero avere un'idea del quadro più ampio.

Dovresti essere in grado di dare una buona idea di ciò che varrà la pena. Il tuo robot semplicemente rallenterà o si fermerà? Prestazioni degradate? O un guasto del robot può causare danni monetari? Perdita della vita?

La risposta a QUESTA domanda dovrebbe spingere la risposta a "vale 13 ore di tempo per le aziende". Avviso: ho detto che il tempo delle aziende. Pagano le bollette e alla fine decidono quanto valga la pena. La tua direzione dovrebbe avere l'ultima parola in entrambi i modi.

Forse parlare con la persona responsabile della definizione delle priorità del lavoro? All'avvio potrebbe essere CTO o proprietario del prodotto. Potrebbe aiutare a scoprire se questo lavoro extra è necessario e perché. Inoltre potresti sollevare le tue preoccupazioni durante le standup quotidiane (se le hai).

Se non esiste una chiara responsabilità (ad esempio il proprietario del prodotto) per la pianificazione del lavoro, prova a parlare con le persone intorno a te. In seguito potrebbe diventare un problema il fatto che tutti spingano il prodotto nella direzione opposta.

Il modo migliore per gestire il disaccordo è lo stesso, indipendentemente dal fatto che tu sia uno sviluppatore junior o uno sviluppatore senior o persino un CEO.

Comportati come Columbo .

Se non hai mai visto Columbo, è stato uno spettacolo davvero fantastico. Columbo era un personaggio senza pretese - la maggior parte della gente pensava che fosse un po 'matto e di cui non valeva la pena preoccuparsi. Ma sembrando umile e chiedendo semplicemente alle persone di spiegare che era in grado di ottenere il suo uomo.

Penso che sia anche legato al metodo socratico .

In generale, vuoi porre domande a te stesso e agli altri per assicurarti di fare le scelte giuste. Non da una posizione di "Ho ragione, ti sbagli", ma da una posizione di onesta scoperta. O almeno il meglio che puoi.

Nel tuo caso hai due idee qui, ma hanno fondamentalmente lo stesso obiettivo: rendere il codice migliore.

Hai l'impressione che lesinare la copertura del codice per un caso potenzialmente improbabile (impossibile?) A favore dello sviluppo di altre funzionalità sia il modo migliore per farlo.

Il tuo collega ha l'impressione che essere più attenti alle custodie angolari sia più prezioso.

Cosa vedono che tu non vedi? Cosa vedi che non vedono? Come sviluppatore junior sei effettivamente in un'ottima posizione perché naturalmente dovresti fare domande. In un'altra risposta qualcuno menziona quanto sia sorprendentemente probabile un caso d'angolo. Quindi puoi iniziare con "Aiutami a capire - avevo l'impressione che X, Y e Z - cosa mi sto perdendo? Perché il widget si rovinerà? Avevo l'impressione che sarebbe scemato in circostanze cromulente. lo stick di swizzle in realtà embiggen i pennelli ANZA? "

Quando metti in discussione le tue assunzioni e le tue scoperte, approfondirai, scoprirai pregiudizi e alla fine scoprirai qual è il corso d'azione corretto.

Inizia con il presupposto che tutti i membri del tuo team siano perfettamente razionali e abbiano in mente i migliori interessi del team e del prodotto, proprio come te. Se stanno facendo qualcosa che non ha senso, allora devi capire cosa non sai che fanno o cosa sai che non fanno.

13 ore non sono un grosso problema, lo farei solo. Ricorda che vieni pagato per questo. Aggiungilo come "sicurezza del lavoro". Inoltre è meglio mantenere un buon karma nella squadra. Ora, se fosse qualcosa che ti richiederebbe una settimana o più, allora potresti coinvolgere il tuo manager e chiedergli se è il miglior uso del tuo tempo, soprattutto se non sei d'accordo.

Tuttavia, sembra che tu abbia bisogno di leva nel tuo gruppo. Ecco come ottenere leva: chiedi perdono, non chiedere il permesso. Aggiungi cose al programma come ritieni opportuno (nell'ambito del corso, ovvero assicurati che risolva completamente il problema che il capo vuole ..), e informa il manager o i tuoi colleghi dopo il fatto. Non chiedere loro: "Va bene se aggiungo la funzione X". Piuttosto, aggiungi solo le funzionalità che desideri personalmente nel programma. Se si arrabbiano con una nuova funzionalità o non sono d'accordo, sii ok per rimuoverla. Se gli piace, tienilo.

Inoltre, ogni volta che ti chiedono di fare qualcosa, fai il "miglio supplementare" e aggiungi molte cose che hanno dimenticato di menzionare o che potrebbero funzionare meglio di quello che hanno detto. Ma non chiedere loro se è "ok" fare il possibile. Fallo e diglielo a caso dopo averlo fatto. Quello che stai facendo è allenarli ...

Ciò che accadrà sarà che il tuo manager ti considererà un "go-getter" e inizierà a fidarsi di te, e i tuoi colleghi inizieranno a vederti come il lead bc che inizierai a possedere il programma. E poi quando succederanno cose come quelle che menzionerai in futuro, avrai di più da dire perché sei essenzialmente la star della squadra e i compagni di squadra si ritireranno se non sei d'accordo con loro.

La revisione del codice ha diversi scopi. Uno di cui sei ovviamente a conoscenza è: " Questo codice è adatto allo scopo? " In altre parole, è funzionalmente corretto; è adeguatamente testato; sono le parti non ovvie opportunamente commentate; è conforme alle convenzioni del progetto?

Un'altra parte della revisione del codice è la condivisione delle conoscenze sul sistema. È un'opportunità sia per l'autore che per il revisore per conoscere il codice modificato e come interagisce con il resto del sistema.

Un terzo aspetto è che può fornire una revisione dei problemi esistenti prima che vengano apportate modifiche. Molto spesso, quando rivedo le modifiche di qualcun altro, vedrò qualcosa che mi mancava in una precedente iterazione (abbastanza spesso qualcosa di mio). Un'affermazione del tipo "Ecco un'opportunità per renderlo più robusto di quanto non fosse" non è una critica e non prenderla come tale!

La mia squadra attuale considera la revisione del codice non solo come un gateway o un ostacolo che il codice deve passare incolume prima del commit, ma principalmente come un'opportunità per una discussione in qualche modo strutturata su una particolare area di funzionalità. È una delle occasioni più produttive per la condivisione delle informazioni. (E questo è un buon motivo per condividere la revisione all'interno del team, piuttosto che sempre lo stesso revisore).

Se percepisci le revisioni del codice come un'attività conflittuale, questa è una profezia che si autoavvera. Se invece li consideri come la parte più collaborativa del tuo lavoro, stimoleranno continui miglioramenti al tuo prodotto e al modo in cui lavori insieme. Aiuta se una recensione può essere chiara sulle priorità relative dei suoi suggerimenti - c'è un miglio di differenza tra "Vorrei un commento utile qui" e "Questo si interrompe se xmai negativo", per esempio.

Avendo fatto molte affermazioni generali sopra, come si applica alla tua situazione specifica? Spero che ora sia ovvio che il mio consiglio è di rispondere alla recensione con domande aperte e di negoziare quale approccio ha più valore. Nel tuo caso di esempio in cui viene suggerito un test aggiuntivo, quindi qualcosa del tipo, "Sì, possiamo testarlo; stima che ci vorrà <time> per implementarlo. Pensi che ne valga la pena il beneficio? E c'è qualcos'altro che può fare per garantire che il test non sia necessario? "

Una cosa che mi colpisce quando leggo la tua domanda: se ci vogliono due giorni per scrivere un nuovo caso di prova, allora il tuo nuovo test è uno scenario molto diverso dai tuoi test esistenti (nel qual caso probabilmente ha molti valore) oppure hai identificato la necessità di un riutilizzo del codice migliorato nella suite di test.

Infine, come commento generale sul valore delle recensioni di codice (e come sommario riassuntivo di ciò che ho detto sopra), mi piace questa affermazione, in Maintainers Don't Scale di Daniel Vetter :

Almeno per me, la recensione non riguarda solo la buona qualità del codice, ma anche la diffusione della conoscenza e il miglioramento della comprensione. All'inizio c'è forse una persona, l'autore (e questo non è un dato), che capisce il codice. Dopo una buona recensione dovrebbero esserci almeno due persone che lo capiscono appieno, compresi casi angolari.

Il codice può SEMPRE essere migliore.

Se stai eseguendo una revisione del codice e non vedi nulla di meglio o un test unitario che potrebbe rilevare un bug, non è il codice perfetto, ma il revisore che non sta facendo il proprio lavoro. Se hai scelto di menzionare il miglioramento è una scelta personale. Ma quasi ogni volta che il tuo team fa una revisione del codice ci dovrebbero essere cose che qualcuno nota che potrebbero essere migliori o che tutti probabilmente hanno perso tempo.

Detto questo, sia che tu agisca sui commenti o meno, dipende dalla tua squadra. Se le tue modifiche risolvono il problema o aggiungono abbastanza valore senza modifiche che il tuo team le accetta, quindi uniscile e registra i loro commenti nel backlog affinché qualcuno possa risolverli in seguito. Se il team rileva che le modifiche apportano più rischi o complessità rispetto al valore, è necessario risolvere i problemi di conseguenza.

Basta ricordare che qualsiasi codice ha almeno un altro caso limite che potrebbe essere testato e potrebbe usare almeno un altro refactoring. Questo è il motivo per cui le revisioni del codice vengono eseguite al meglio come gruppo con tutti che guardano lo stesso codice contemporaneamente. In modo che alla fine tutti possano giungere a un consenso sull'accettabilità o meno del codice in esame (così com'è) e sull'aggiunta di un valore sufficiente per fondersi nella base della comunità o se alcune cose devono essere fatte prima che ci sia abbastanza valore da unire .

Dato che stai ponendo questa domanda, suppongo che in realtà non stai facendo "revisioni del codice", ma piuttosto creando una richiesta pull o un altro meccanismo di invio affinché altri possano commentare in modo non deterministico. Quindi ora sei in un problema di gestione e una definizione di fatto. Immagino che la tua gestione non sia decisiva e in realtà non comprenda il processo e lo scopo delle revisioni del codice e probabilmente non abbia una "definizione di fatto" (DOD). Perché se lo facessero il tuo DOD risponderebbe esplicitamente a questa domanda e non dovresti venire qui e chiedere.

Come lo risolvi? Bene, chiedi al tuo manager di darti un DOD e di dirti se devi sempre implementare tutti i commenti. Se la persona in questione è il tuo manager, la risposta è evidente.

Questa domanda non riguarda le virtù della programmazione difensiva, i pericoli di casi angolari o i rischi catastrofici di bug nei prodotti fisici. In realtà non si tratta nemmeno di ingegneria del software .

Di cosa si tratta è come un praticante junior gestisce le istruzioni di un praticante senior quando il junior non può essere d'accordo o apprezzarlo.

Ci sono due cose che devi apprezzare per essere uno sviluppatore junior. In primo luogo, ciò significa che, sebbene sia possibile che tu abbia ragione e che lui abbia torto, è - a conti fatti delle probabilità - non probabile. Se il tuo collega sta suggerendo che non riesci a vedere il valore di, devi prendere seriamente in considerazione la possibilità che tu non abbia abbastanza esperienza per capirlo. Non ho questo senso da questo post.

La seconda cosa da apprezzare è che il tuo partner senior è così chiamato perché ha più responsabilità. Se un giovane rompe qualcosa di importante, non seguiranno i problemi se seguiranno le istruzioni. Se un anziano permettesse loro di romperlo, tuttavia - non sollevando problemi nella revisione del codice, ad esempio - sarebbe giustamente molto preoccupato.

In definitiva, è un requisito implicito del tuo lavoro osservare le istruzioni di coloro di cui l'azienda si fida per guidare i propri progetti. Non sei generalmente in grado di rinviare agli anziani quando c'è una buona ragione per valutare la loro esperienza? Intendi seguire nessuna istruzione che non riesci a capire? Pensi che il mondo dovrebbe fermarsi fino a quando non sarai convinto? Questi valori sono incompatibili con il lavoro in gruppo.

Un ultimo punto. Ripensa ai progetti che hai scritto sei mesi fa. Pensa ai progetti che hai scritto all'università. Vedi quanto adesso sembrano cattivi: tutti i bug e il design capovolto, i punti ciechi e le astrazioni sbagliate? E se ti dicessi che tra sei mesi conterai gli stessi difetti nel lavoro che stai facendo oggi? Questo aiuta a dimostrare quanti punti ciechi ci sono nel tuo attuale approccio? Perché questa è la differenza che l'esperienza fa.

fa costantemente commenti al mio codice che mi suggeriscono di fare molto più lavoro di quanto sia necessario.

Puoi dare consigli, ma alla fine non è il tuo ruolo decidere cosa è necessario. Il tuo compito è implementare ciò che la gestione o (in questo caso il tuo revisore) decide è necessario. Se non sei d'accordo con ciò che è necessario troppo o troppo fortemente, probabilmente ti ritroverai senza lavoro. Di conseguenza fa parte della tua professionalità venire a patti con questo ed essere in pace con esso.

Mi aveva suggerito di gestire un caso oscuro che è estremamente improbabile che accada

Ci sono altre grandi risposte qui che mostrano come anche i non-bug (cioè qualcosa che non può mai fallire ) dovrebbe essere rielaborato a volte. (ad esempio nel caso di costruire in futuro la sicurezza del prodotto, seguendo gli standard ecc.) Parte del ruolo di un grande sviluppatore è avere la massima sicurezza possibile che il tuo codice sarà solido in ogni situazione immaginabile ogni volta e in futuro anche a prova di errore, non solo lavorando in situazioni testate nelle condizioni attuali per la maggior parte del tempo

Suggerimenti per i revisori del codice per aumentare l'utilità aziendale della tua revisione del codice (tu come OP dovresti proporre tale modifica):

• Contrassegna i tuoi commenti per tipo. "Critico" / "Must-Do" / "Opzionale" / "Miglioramenti suggeriti" / "bello avere" / "Sto meditando".

  Se questo sembra troppo CDO / anale / complicato, almeno usa 2 livelli: "Devi correggere per passare la revisione e avere il permesso di unire la tua modifica" / "Tutti gli altri".

Suggerimenti per la gestione dei suggerimenti per la revisione del codice che sembrano meno importanti da formulare:

• Crea un biglietto aperto nel tuo sistema di ticketing preferito (il tuo team ne utilizza uno, si spera?), Tenendo traccia del suggerimento

• Inserisci il ticket # come commento di risposta all'elemento di revisione del codice se il tuo processo consente risposte a commenti come Fisheye o recensioni di e-mail.

• Contatta il revisore e chiedi esplicitamente se l'articolo è del tipo "deve risolvere o non verrà unito / rilasciato".

  • Se la risposta è "Sì", ma non sei d'accordo, lascia che la persona responsabile della gestione del progetto (PM, il tuo manager, ecc ...) prenda una decisione - presenta il disaccordo in modo completo e onesto. Non si tratta di chi di voi è "giusto", ma di ciò che è meglio per il progetto, quindi il lavoro di PM / manager.

Ora, considera quel ticket come qualsiasi altra richiesta di sviluppo.

1. Se si decide di essere urgenti dopo l'escalation, trattarlo come qualsiasi richiesta di sviluppo urgente. Deprioretize altri lavori e lavorare su questo.

2. Altrimenti, lavoraci in base alla priorità che gli è stata assegnata e al suo ROI (che può differire in base alla tua linea di business come spiegato in altre risposte).

Non dovresti inoltrarlo alla direzione.

Nella maggior parte delle società, il dirigente sceglierà sempre di non scrivere quel test aggiuntivo, di non perdere tempo a migliorare marginalmente la qualità del codice, di non perdere tempo a eseguire il refactoring.

In molti casi la qualità del codice dipende dalle regole non scritte nel team di sviluppo e dallo sforzo extra che i programmatori mettono in atto.

Sei uno sviluppatore junior e questa è la tua prima recensione di codice . Devi accettare i consigli e fare il lavoro. Puoi migliorare il flusso di lavoro e le regole del tuo team solo se li conosci e li rispetti per un po 'in modo da poter capire perché sono lì. Altrimenti sarai quel nuovo ragazzo che non rispetta le regole e diventa il lupo solitario della squadra.

Sei nuovo nel team, segui i consigli che ricevi per un po ', scopri perché sono lì, non portare i primi consigli che metti in discussione durante la riunione della mischia. Le vere priorità aziendali ti saranno evidenti dopo un po 'senza chiedere (e potrebbe non essere ciò che il manager ti dirà faccia a faccia).

È molto importante creare un codice che soddisfi la richiesta di lead / gestione. Qualsiasi altro dettaglio sarebbe semplicemente "bello da avere". Se sei un esperto (leggi che: "se non sei uno sviluppatore junior") nel tuo campo, allora sei "idoneo" ad affrontare i problemi minori che trovi lungo la strada senza consultare ogni volta i tuoi leader.

Se pensi che qualcosa non vada e sei relativamente esperto nel tuo campo, allora è probabile che tu abbia ragione .

Ecco alcune affermazioni che potrebbero esserti utili:

• Mi è stato chiesto di fare X, il revisore del codice suggerisce di fare anche Y, dovrei farlo o dovrei passare a cose più importanti?
• Mi stai suggerendo Y, quindi puoi capire almeno un caso di test che catturerebbe quel comportamento in modo che io possa provarlo? Credo che il codice non verrà chiamato.
• Forse non dovremmo sviluppare prima un fallback sicuro per i casi scoperti? Quindi li prendiamo presto e ci sistemiamo in viaggio in modo che possiamo concentrarci su cose più importanti.
• OK, mentre sto implementando Y, potresti essere così gentile da scrivere alcuni casi di test per farlo in modo da fare quella cosa una volta per tutte ?
• Mi è stato chiesto di fare X, e penso che potrei fare Y se non ci sono altre priorità. La prossima volta perché non presentare una richiesta di funzione anziché inserirla come commento di revisione sul mio codice ? Almeno possiamo ascoltare ulteriori opinioni dagli altri membri del team su quella caratteristica prima di implementarla (in genere qualsiasi elemento importante dovrebbe essere una caratteristica e dovrebbe essere gestito da più di una persona; di solito la revisione del codice dovrebbe riguardare la revisione del codice e gli approcci delle soluzioni; il resto è bug-fixing e funzionalità).

Pensi seriamente che l'atteggiamento del tuo recensore stia danneggiando il progetto o pensi che abbia ragione la maggior parte delle volte (tranne forse a volte commette solo piccoli errori nella valutazione e lo esagera)?

Per me sembra più che stia scrivendo cose che non appartengono a una revisione del codice, il che è una cattiva pratica perché rende più difficile per tutti tenere traccia delle cose. Tuttavia non so quali altri commenti di recensioni abbia fatto, quindi non posso dire nulla su altri casi.

In generale, cerca di evitare entrambi i seguenti:

• Non stai facendo ciò che è stato richiesto
• Fai sembrare stupido il tuo recensore

Se sta effettivamente rivedendo il tuo codice, è perché la gestione si fida di lui più di te.

In caso di disaccordo durante la revisione del codice sull'ambito:

1. Documentare l'ambito effettivamente coperto dal codice. A nessuno piacciono le brutte sorprese.
2. Comprendi che l'ambito di applicazione è una decisione aziendale. Scope dovrebbe essere già noto quando inizi a lavorare su una funzione, ma in caso contrario puoi sempre chiedere chiarimenti in seguito.

Se il revisore del codice è quello che prende le decisioni aziendali, può cambiare l'ambito in qualsiasi momento, anche durante la revisione del codice, ma non lo sta facendo nel suo ruolo di revisore del codice.

Se non riesci a dimostrare che il caso limite sia impossibile, devi presumere che sia possibile. Se è possibile, allora è inevitabile che alla fine accada, e prima piuttosto che dopo. Se il caso limite non si è verificato durante il test, ciò potrebbe suggerire che la copertura del test è incompleta.

1. Accetta il feedback.
2. Prima di apportare modifiche al codice, fai del tuo meglio per creare un test per il caso limite e vedere se riesci a ottenere un errore di prova (prova dell'esistenza del problema). Se è impossibile creare un caso del genere un test e ottenere un fallimento del test, allora si potrebbe essere in grado di concludere che il caso limite è in realtà impossibile (anche se mi piacerebbe essere riluttanti a trarre una simile conclusione).
3. Se è possibile ottenere un errore del test, applicare la modifica del codice appropriata per superare il test.

Per il bene del prodotto, probabilmente vuoi essere in grado di produrre la custodia perimetrale e indurre un errore, in modo da poter applicare la correzione e avere la certezza che un potenziale problema è stato evitato.

L'intero punto delle revisioni del codice è quello di dare un ulteriore sguardo al codice. Nessuno di noi è immune da errori o sviste. È fin troppo comune guardare un pezzo di codice molte volte e non notare un errore evidente, in cui un paio di occhi nuovi possono prenderlo immediatamente.

Come hai detto, hai implementato un nuovo algoritmo. Non sarebbe saggio trarre conclusioni sul comportamento del tuo nuovo algoritmo in base al comportamento o alle osservazioni sul suo predecessore.

Ci sono revisori del codice che sanno cosa stanno facendo e se dicono che qualcosa deve essere cambiato, allora deve essere cambiato, e quando dicono che qualcosa deve essere testato, allora deve essere testato.

Ci sono revisori del codice che devono giustificare la propria esistenza creando lavoro inutile per gli altri.

Quale è quale devi decidere, e come gestire il secondo tipo è più una domanda per workplace.stackexchange.

Se usi scrum, allora la domanda è se il tuo lavoro fa quello che dovrebbe fare (apparentemente lo fa), e puoi mettere sul backlog la gestione del caso estremamente raro e forse impossibile, dove verrà data la priorità e se partecipa a uno sprint, quindi il tuo recensore può sentirsi libero di prenderlo e fare il lavoro di 13 ore. Se fai il lavoro X e poiché fai il lavoro X ti rendi conto che anche il lavoro Y deve essere svolto, allora il lavoro Y non diventa parte del lavoro X, è il suo lavoro indipendente.