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


188

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.


152
Ti rendi conto che i test unitari sono, in parte, destinati a rilevare quei difetti da un milione di persone quando qualcuno verifica una modifica al tuo codice che lo rompe in qualche modo oscuro, giusto? I test unitari non si limitano a garantire che il codice sia corretto ora , ma anche in tre anni in cui qualcun altro mantiene il codice che hai scritto.

189
@Klik "Il vero input non sarà mai così" Ecco dove ti sbagli. Ho riscontrato troppi casi di "input non sarà mai così" e di essere sorpreso quando era "così". In un ambiente di produzione, possono succedere cose strane di ogni genere. Non pensare solo a come il vostro software funzionerà , ma anche come sarà fallire?

38
@Snowman Più in particolare le revisioni del codice puntano , in parte, a rilevare quei difetti su un milione che i test unitari e persino i test / fuzzing randomizzati non trovano.
Derek Elkins,

11
Vale anche la pena ricordare che le revisioni del codice non sono solo lì per cogliere i problemi, ma sono anche lì per imparare come potresti essere in grado di fare meglio, quindi trattale come un'opportunità di apprendimento.
Steve Barnes,

72
hey @Klik, sembra che il problema fondamentale qui sia che hai "paura di dire la tua mente". MAI essere arrabbiato, SEMPRE esprimi la tua mente - con un sorriso. Avresti dovuto dire immediatamente al ragazzo: "Hmm, mi ci vorranno almeno due giorni, ne vale la pena, chiediamo al nostro capo?" e in secondo luogo avresti dovuto dire "Non dimenticare che stiamo lavorando alla robotica, in realtà non è possibile che il sensore sinistro sia alla destra del sensore destro - chiediamo al capo quanti casi angolari anti-fisici vogliamo coprire". Il tuo problema è tuo , il tuo problema è che devi scambiare rabbia per parlare .
Fattie,

Risposte:


227

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.


9
@ 9000 Può anche essere frustrante quando la risposta è "perché la vita è così". Ad esempio, questo è quello che ho dovuto affrontare di recente: "Usa gli spazi sulle schede". "Perché?" "Perché la nostra guida di stile dice a". "Perché?" "Non lo so; non l'ho scritto." "Ah, chiaramente hai torto e ho ragione, e ho intenzione di lasciare il mio codice con le schede!" Quindi un hook post-commit lo ha cambiato comunque, ma comunque - se usi la tecnica dei 5 perché, vai fino a quando non hai ottenuto una risposta ragionevole, non fino a quando non hai frustrato l'altra persona.
Nic Hartley,

111
@QPaysTaxes: tutti dovrebbero sapere il perché degli spazi sulle schede (o sulle schede sugli spazi) argomento: perché entrambi sono corretti ma la coerenza è più importante, quindi scegline uno, sii coerente e non perdere tempo a pedalare
slebetman

30
Not having untested behaviors in code can be very important. If a piece of code is run e.g. 50 times a second, a one in a million chance will happen approximately every 5.5 hours of runtime. (In your case, the odds seem lower.)-- Che cosa? No. A meno che tu non stia eseguendo una simulazione Monte-Carlo o il tuo codice includa qualche elemento randomizzato. I computer non eseguono il software secondo una curva a campana o una deviazione standard a meno che non gli dica espressamente di farlo.
Robert Harvey,

10
@RobertHarvey: considera qualcosa come una condizione di gara, che è esattamente un elemento randomizzato. Considerare anche un bug dipendente dai dati durante l'elaborazione dei dati in streaming; mentre i dati potrebbero non essere del tutto casuali, ma a meno che non siano altamente ripetitivi, una particolare combinazione di byte può verificarsi più volte. Uno su un milione = attivato da una particolare combinazione di 20 bit, un bug come questo sarebbe immediatamente visibile se si elaborasse un flusso video; qualcosa che accade raramente ma regolarmente potrebbe comportare, ad esempio, 40 bit.
9000

7
@RobertHarvey: Molto probabilmente! Volevo solo sottolineare che ci sono pezzi di codice che potrebbero avere una probabilità 1e-6 (non 0 e non 1) di infrangersi in una particolare invocazione, riferendosi al «caso oscuro che è estremamente improbabile che accada». Mentre i bug di questo tipo di solito non sono visibili durante i test, sono visibili in produzione.
9000

323

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.

Inserisci qui la descrizione dell'immagine

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.


102
Oh mio Dio questa risposta è. L'OP ha a che fare con software che ha ripercussioni fisiche. Il bar è stato alzato. Probabilmente il revisore non ha realizzato questo "caso limite" fino a quando non ha ripreso a guardare il codice. E dato abbastanza tempo nulla è un caso limite. Non vuoi far accidentalmente oscillare il braccio di un robot nella testa di qualcuno (non che io sappia che un braccio robot è coinvolto in questo codice).
Greg Burghardt,

11
Greg e Steve, questo è un ottimo esempio, ma è un esempio di bug . È un insetto oscuro semplice. Letteralmente "un bug", dividendo per zero. Quando lavori sugli algoritmi di robotica, è un'idea centrale che pensi a concetti fisicamente possibili e non fisicamente possibili. (Se vuoi, concetti "non ancora" fisicamente possibili, con i dispositivi attuali.) La confusione tra i due sviluppatori, qui in discussione qui, è dovuta al fatto che (sorprendentemente) non sono all'altezza di questo paradigma. Tutta la loro squadra ha seri problemi se i tizi più anziani non hanno incorporato quel paradigma.
Fattie,

11
Penso che ci siano esempi del mondo reale che dimostrano perché i casi limite dovrebbero essere coperti, ma questo non è uno di questi. L'esempio citato è un caso di utilizzo della libreria errata per un'attività. Il codice per una banana non deve essere utilizzato alla cieca su un'arancia. È colpa della persona che ha usato il codice banana su un'arancia, non la persona che ha scritto il codice per un'arancia che non è in grado di gestire una banana. (Ho dovuto cambiare Apple per Banana in questa analogia a causa di una grande azienda tecnologica là fuori ...)
Origine

51
@JoeBlow Un bug, sì, ma prevenibile , che avrebbe potuto essere scoperto con ulteriori casi di test e / o revisioni del codice. Dio solo sa se c'era un ragazzo lì a un certo punto che diceva "Sai ragazzi, penso che dovremmo convalidare questo intervallo ..." e altri che dicono "Non preoccuparti ... cosa potrebbe andare storto con un caso impossibile ? " Se i bug non sono abbastanza prove del fatto che la nostra logica ha più lacune di quanto vorremmo, allora non so cosa dire ...
code_dredd

30
Il punto che stavo cercando di sottolineare è che non dovresti ignorare i casi di test come mai accaduti, estremamente improbabili, ecc., Gli standard per cui stavano codificando richiedevano il controllo dell'intervallo 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 3 non si trattava di un bug, ma di un mancato rispetto degli standard. Se il codice fosse stato riutilizzato in uno scenario diverso se non fosse riuscito in modo catastrofico, mentre se l'intervallo di valori fosse stato troncato, sarebbe probabilmente fallito con garbo.
Steve Barnes,

84

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.


19
Penso che questo sia il punto chiave, sebbene la copertura del caso aggiuntivo sia effettivamente un utile e valido miglioramento, non è necessario che venga suddiviso in una PR esistente per diversi motivi.
DeadMG

6
Anche se è stato gestito prima, è anche irrilevante l'IMO, semplicemente non era nella descrizione dell'attività in anticipo.
Jasper N. Brouwer,

6
Per fare eco a questo sentimento, una buona risposta per fare commenti può essere "Solleverò un biglietto per coprirlo, buon punto". Ciò riconosce che la "cosa" deve essere fatta, permettendo allo stesso tempo di dare priorità a tutto il resto del lavoro che deve essere fatto.
Edd,

17
Non potrei essere più in disaccordo. Il fatto che questo problema potrebbe non essere stato sollevato durante l'implementazione iniziale della funzionalità potrebbe altrettanto facilmente - dal momento che non conosciamo i dettagli - potrebbe essere indicativo di essere stato incredibilmente fortunato fino ad ora in quanto potrebbe essere inutile. La revisione del codice di una modifica che cambia il modo in cui funziona questo algoritmo - aumentando potenzialmente la probabilità di questo caso limite - è esattamente il momento di far emergere potenziali problemi. Se sia al di fuori del campo di applicazione dovrebbe essere deciso dopo un'adeguata valutazione di ciò, non deciso fuori mano con poco contesto.
Matteo Leggi il

6
Questo è un consiglio terribile! Since it wasn't handled before, it's out of the scope for your effortbasterebbe contrassegnare ogni singolo report di bug come wontfix, supponendo che le tue specifiche fossero abbastanza cattive per cominciare con che non prendevano in considerazione i casi limite, se avessi anche una specifica adeguata.
Filip Haglund,

53

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.


7
Fai un ottimo punto nel secondo paragrafo. L'ho già sperimentato prima, ma articolarlo è molto utile.
Klik,

7
Terzo caso = bingo. Lavoro principalmente nel codice legacy e ci sono progetti in cui l'80% del lavoro sta semplicemente riparando posti che hanno fatto ipotesi. Mi piace questa risposta così com'è, ma aggiungerei che a volte va bene coprire un caso limite così impossibile impostando un errore grazioso con un messaggio di errore esatto e dettagliato, specialmente quando sei in una crisi di tempo.
Jeutnarg,

Mi piace registrare le eccezioni che dicono "[Descrizione dell'errore] Secondo la specifica [versione] firmata da [persona che l'ha firmata] ciò non può accadere."
Peter vinto il

Ma poiché prima non esisteva un caso di test, il codice (supponendo che le specifiche sostituissero il precedente) non dovrebbe adattarsi a nuovi casi di test in quella iterazione. E se non esiste già un test per quel caso d'angolo, dovrebbe essere un nuovo ticket / attività da eseguire, non un feedback di revisione del codice imo.
kb.

38

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.


5
Esatto, chiedi a qualcun altro se vale la pena coprirlo. Almeno scriverei il caso di prova e poi lo contrassegnerei come "ignorato" con commenti che dicevano che qualcun altro ha deciso che non valeva la pena implementarlo. CYA
Sean McSomething,

2
Sì, ogni volta che qualcosa di grosso, fuori portata ma non urgente emerge in una revisione del codice, tendiamo a creare un problema per esso nel nostro tracker e quindi dare la priorità insieme al resto delle altre cose che dobbiamo fare. Occasionalmente ciò significa che l'attività viene espulsa fino alla fine dell'elenco delle priorità, ma in tal caso non è davvero importante.
Tacroy,

1
"Non è la probabilità, è la posta in gioco!"
user1068

2
Questa è la risposta migliore La domanda riguarda davvero la definizione delle priorità e la gestione dei rischi.
wrschneider,

Sono d'accordo con questa decisione commerciale. Crea un ticket con la stima del tempo necessario per risolverlo, assegnalo al tuo capo (chiunque sia nella catena di comando è responsabile dell'assegnazione del tuo tempo) e chiedi che gli venga assegnata una priorità (o rifiutata, a seconda dei casi) può essere)
Matija Nalis,

21

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


2
"Presentalo nel modo più neutro che puoi" ... abbastanza. Vorrei andare oltre NeilS e suggerirei, come si suol dire, che devi scambiare "rabbia per parlare". Dì solo all'istante e apertamente (ad esempio, nell'esempio specifico a portata di mano), "Steve, la tua valigetta angolare non è fisica con l'attuale design meccanico, non pensi amico? Innanzitutto decidiamo se non è fisica, e anche se vale la pena dedicare due giorni ".
Fattie,

1
"Se si utilizza uno strumento di revisione" è un'osservazione chiave. IME, questi strumenti sono adeguati per tenere un registro della revisione, ma il vero lavoro viene svolto faccia a faccia con la discussione. È il modo più efficiente per un flusso di informazioni bidirezionale. Se non si è d'accordo con una revisione, avere tale disaccordo in modo costruttivo di persona e solo allora inserire il risultato concordato nello strumento.
Toby Speight,

@TobySpeight: sono d'accordo e ho cercato di incorporarlo nella risposta.
Neil Slater,

1
2 ore sono più ciò che non vorrei combattere. 2 giorni e non riuscirò a finire tutte le altre attività che mi sono impegnata per la settimana.
Matteo Leggi il

15

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.


Completamente d'accordo. Se c'è qualche caso che il tuo codice non può gestire, controlla l'input il più presto possibile e fallisci lì. "Il programma si arresta in modo anomalo se eseguiamo X" è sempre meglio di "Il nostro robot uccide le persone se eseguiamo X"
Josef

1
Buon consiglio Un buon codice è un codice che ha dimostrato di non fallire mai ma, se fallisce inspiegabilmente a prescindere, fallisce in un modo ben definito che può essere riparato. Il codice che non può andare storto ma, se va storto, risulta impossibile da ottenere o riparare, non è così eccezionale ...
leftaroundabout

Questo, stavo per pubblicare la stessa identica cosa. Il revisore sta sottolineando un possibile fallimento, come gestirlo è una domanda diversa.
SH-

2
Oh, no, non fare un'affermazione nel tuo codice. Se l'asserzione non viene compilata, nessuno lo vedrà mai. Se l'asserzione viene compilata, il robot si arresterà in modo anomalo. Ho visto più di un caso in cui un'affermazione per "qualcosa che non potrebbe mai accadere" nel codice di produzione ha innescato e fatto cadere non solo quel sistema ma tutto ciò che dipendeva da esso.
Tom Tanner,

@TomTanner "con una buona gestione degli errori, che dovrebbe già essere in atto". Presumo che il codice sia già in grado di gestire asserzioni non riuscite qui. Il che potrebbe non essere molto lungo, dal momento che le strategie di fallimento sicuro dovrebbero far parte di qualsiasi sistema fisico.
WorldSEnder,

13

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.


7

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.


1
Inoltre, quali sono le ripercussioni sulla responsabilità di un difetto noto che non è stato risolto, anche se oscuro?
chux,

5

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.


5

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.


3

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.


8
Mentre sono tutti per i programmatori che sono proattivi e non semplicemente "prendono ordini dall'alto", il modo in cui lo presenti è professionalmente irresponsabile e non etico. In pratica stai dicendo che l'OP dovrebbe spendere il tempo e il denaro del datore di lavoro non lavorando sulle funzionalità richieste ma invece lavorando sulle funzionalità che "desidera" personalmente, e quindi spendere il tempo e il denaro del datore di lavoro per rimuovere tali funzionalità. Ciò non tiene conto nemmeno dei potenziali difetti che vengono aggiunti o del tempo di altri sviluppatori per la revisione / manutenzione del codice. Vorrei licenziare uno sviluppatore con l'atteggiamento che descrivi, in particolare uno junior.
Derek Elkins,

1
Beh, hai ragione in un certo senso. Soprattutto se l'ingegnere si spegne da solo senza alcuna sensibilità su quale sia la visione del cliente. Ma non sabotare ciò che ho detto completamente, ho semplicemente detto di fare il "miglio supplementare". Questo significa che prendi ciò che dice il tuo capo e ti espandi. E nel software, questa è la differenza tra un software che sembra una merda banale e un software che sembra realizzato da un professionista. Conosco molti sviluppatori che fanno "esattamente ciò che viene loro detto" anche se ciò che viene detto è spazzatura completa. Quegli sviluppatori non equivalgono mai a nulla.

2
Ci sono modi responsabili per fare ciò che descrivi. Molte volte i requisiti lasciano molto spazio e usare il tuo giudizio lì per produrre un risultato più raffinato (bilanciato con lo sforzo, incluso lo sforzo di manutenzione, per raggiungerlo) è una buona cosa. In genere, evidenziare e correggere in modo proattivo i bug va bene. Trascorrere del tempo per prototipare una funzionalità che ritieni sia nell'interesse dell'azienda e presentarla al team per una possibile inclusione va bene. I tuoi "desideri personali" sono irrilevanti, mentre l'attenzione per il tuo pagamento dovrebbe essere rivolta agli interessi dell'azienda.
Derek Elkins,

Vedi il mio secondo commento, per come vorrei presentare ciò in cui credo sia l'idea che stai cercando di ottenere. Come ho detto, il mio problema è più legato al modo in cui lo hai presentato. Gli sviluppatori hanno bisogno di un po 'di orgoglio per sapere che possono prendere decisioni significative, ma l'umiltà di sapere che (di solito) non hanno una visione ampia degli obiettivi o delle priorità dell'azienda. Più sviluppatori senior hanno meno probabilità di prendere decisioni sbagliate e hanno maggiori probabilità di sapere quali sono gli obiettivi dell'azienda e come muoversi verso di loro.
Derek Elkins,

nota inoltre che il mio commento è rivolto a coloro che desiderano passare al livello guida o consulente. Le aziende mi assumono specificamente per la mia opinione.

3

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.


3

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.


3

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.


2

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


2

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


2

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


Sfortunatamente, mentre hai iniziato bene, la tua raccomandazione finisce per essere piuttosto negativa.
Joshua,

1

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


-1

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.


questo non sembra offrire nulla di sostanziale rispetto ai punti formulati e spiegati nelle precedenti 20 risposte
moscerino

-1

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.


questo non sembra offrire nulla di sostanziale rispetto ai punti formulati e spiegati nelle precedenti 21 risposte
moscerino del

-2

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.


6
Questo è troppo vago ed emotivo per essere un consiglio utile.
Robert Harvey,

L'osservazione su SCRUM è assolutamente corretta, i juts compiono un nuovo compito nel backlog. Rimuovi l'inizio maleducato della tua risposta e riceverai un punteggio positivo.
xmedeko,
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.