Fail Fast vs. Solidità

Question

Il nostro prodotto è un sistema distribuito. I moduli su cui lavoro sono abbastanza nuovi, abbastanza rigorosi, ben testati. Sono stati sviluppati tenendo conto delle recenti migliori pratiche. Altri moduli possono essere considerati come software legacy.

Mentre sono attento a tutto ciò che accade nei moduli di cui sono responsabile, sono costantemente sotto pressione per lavorare con dati errati che mi vengono inviati dagli altri moduli. In fondo, sono uno sviluppatore del principio "Fail Fast" e di conseguenza, quando sorgono problemi, di solito sono in grado di eliminare la possibilità di errore nei miei moduli. Non si tratta tanto di incolpare, ma di risparmiare sforzi inutili per inseguire i bug nei posti sbagliati.

Ma l'argomento che continuo a discutere è: "Non possiamo lasciare che questa roba fallisca in produzione, il cliente si aspetta che funzioni, perché non si lavora su questo problema". E questo sarebbe un argomento di solidità: sii liberale in ciò che accetti, conservatore in ciò che mandi.

Devo anche notare che si tratta principalmente di problemi intermittenti. Li vediamo nei test di integrazione ma sono difficili da riprodurre. Cronometraggio e concorrenza sono coinvolti.

Ho difficoltà a bilanciare i due principi. In parte è la mia preoccupazione che se inizio a permettere e diffondere dati eccezionali, sto invitando problemi e non avrò più tanta fiducia nel mio sistema. Ma non posso discutere contro il mantenimento del sistema operativo anche se altri moduli mi stanno inviando dati errati. La ragione per cui altri moduli non vengono sistemati è che sono troppo complessi e fragili, mentre i miei appaiono ancora chiari e sicuri. Ma se non resisto alla pressione, i miei moduli verranno lentamente sellati con gli stessi problemi che ho rifiutato fino ad ora.

Devo dire che il sistema non si sta "bloccando" in produzione, ma il mio modulo potrebbe semplicemente visualizzare un errore all'operatore e chiedere loro di contattare l'assistenza. Un incidente sarebbe un grosso problema, ma se sto segnalando chiaramente l'errore, allora non è questa la cosa giusta da fare? Sospetto che i miei colleghi non vogliano che il cliente veda qualche problema, punto. Ma il mio modulo sta rifiutando i dati da altri moduli all'interno del nostro prodotto, non dall'input del cliente. Quindi mi sembra che non stiamo affrontando problemi.

Quindi, devo essere più pragmatico o tenere la mia terra?

Answer 1

Grazie a tutti. Il caso che ha spinto questa domanda è finito bene, e in parte grazie agli approfondimenti che ho avuto dalle risposte sopra.

La mia prima reazione è stata quella di attenermi al fail veloce, ma ci ho pensato un po 'di più, ed ero giunto alla conclusione che uno dei ruoli del mio modulo era quello di fornire un ancoraggio stabilizzante al resto del sistema. Ciò non significa necessariamente accettare dati errati, ma far emergere problemi, isolarli e gestirli in modo trasparente finché non troviamo una soluzione.

Ho pianificato l'aggiunta di un nuovo gestore e percorso di codice per questo caso, che verrebbe eseguito correttamente come se si trattasse di un caso di utilizzo speciale precedentemente non documentato.

Abbiamo avuto una discussione in cui ho ribadito la necessità di affrontare il problema al confine, ma ero anche disposto ad aiutare. Ho delineato il mio piano dall'altra parte, perché avevo il sospetto che la mia posizione fosse considerata eccessivamente pedante e che la soluzione fosse percepita come se dovessi solo disattivare la convalida spuria di dati innocui, anche se non era corretta. In realtà però, il modo in cui lavoro è in gran parte guidato dai dati, quindi ho spiegato perché deve essere corretto e in che modo il comportamento è guidato da esso e in che modo nell'accogliere questi dati implementerò un percorso di codice speciale.

Penso che questo abbia dato peso alla mia posizione e ha portato a una discussione più approfondita sull'avversione dell'altro lato alla correzione dei dati. Si è scoperto che era più una stanchezza di affrontare un sistema legacy soggetto a errori che un ostacolo reale. C'era una soluzione relativamente semplice, era solo spaventoso fare un cambiamento, una mentalità piuttosto arroccata.

Ma dopo aver ventilato tutte le sfide e le possibili soluzioni, alla fine abbiamo deciso di fissare i dati, e finora sembra aver risolto il nostro problema. I nostri test di integrazione stanno ora passando in modo coerente, ma abbiamo anche aggiunto il logging e continueremo a monitorarlo.

In sintesi, penso che per me, la sintesi di entrambi i principi è che il fail veloce è essenziale per i problemi di superficie. Ma una volta che sono in superficie, robustezza significa fornire un percorso trasparente per continuare a operare in un modo che non comprometta il sistema. Sono stato in grado di offrirlo e, così facendo, ho guadagnato un po 'di buona volontà dall'altra parte e ho risolto i dati alla fine.

Ancora grazie a tutti quelli che hanno risposto. Sono troppo nuovo per valutare i commenti, ma apprezzo tutte le prospettive presentate.

Answer 2

Direi che dipende da cosa succede se non si ferma. Lo stipendio di qualcuno viene elaborato in modo errato? Viene spedito l'ordine sbagliato? Vale la pena fermarsi per questo.

Se possibile, mangia la torta e mangiala anche tu - non segnalare l'errore all'utente, chiedere al cliente di accettare l'invio di rapporti diagnostici e segnalare ogni errore. Bug agli sviluppatori che possiedono il/i modulo/i in errore per risolverli. E con un bug intendo un bug su di loro. Oppure, se la direzione non pensa che valga la pena di riparare, non farlo.

Scriverò anche test di unità contro quei moduli che non riescono, soprattutto se si può dire quale sia stato l'input originale che ha causato loro di generare l'output sbagliato.

Ciò che in realtà viene in mente è ciò che la persona che rivede le tue prestazioni desidera da te, soprattutto dopo aver spiegato il problema a loro, via email.

Answer 3

Questo è un problema. Se il tuo modulo riceve dati errati ed è "ok" perché tu non faccia nulla con loro e torni, allora ti suggerirei di scrivere in un log degli errori invece di mostrare un errore all'utente.

Answer 4

In poche parole, questo sembra un "non controllare per qualcosa che non si può gestire". Il fatto che tu stia rilevando l'errore e sia in grado di segnalarlo significa che non lo stai propagando.Ma significa anche che dal momento che è possibile segnalarlo, si dispone di un meccanismo per intercettare l'errore e, quindi, potenzialmente gestirlo da soli e correggerlo piuttosto che segnalarlo.

Mind, sto assumendo che il tuo rapporto di errore è più interessante di un'eccezione casuale che hai notato in qualche posto nel profondo del sistema. Ma anche in questo caso, se si tratta di un'eccezione che stai provando e stai creando (ovvero controlli se il denominatore è zero e invii un errore anziché semplicemente dividendolo inavvertitamente per zero e rilevando l'eccezione più in alto), allora questo ti suggerisce potrebbe avere un modo di correggere il problema

In conclusione, avete bisogno di entrambi. È necessario provare a rendere i dati privi di errori nel modo più pratico, ma anche riportare gli imprevisti.

Non credo che si possa chiudere a chiave la porta e incrociare le braccia dicendo "non è un mio problema". Il fatto che provenga da "vecchi sistemi fragili" non ha senso. IL TUO CODICE NON È VECCHIO UN LUOGO FRAGILE E NECESSARIO, IN EFFETTO DELL'INTERO SISTEMA INTEGRATO, PER "RISOLVERE" I DATI, una volta rilevato il problema. Sì, i vecchi moduli continueranno a GIGO per altri sistemi minori, ma quei moduli legacy combinati con il tuo nuovo modulo sono un tutt'uno coeso e quindi costituiscono il "sistema".

Il tipico problema reale qui è semplicemente l'equazione tempo/valore di scrivere tutto questo codice di correzione rispetto alle nuove funzionalità. Questo è un dibattito diverso. Ma se hai tempo e sai cose che puoi fare per ripulire i dati in arrivo, "essere liberale in ciò che accetti" è una buona politica.

Answer 5

Non entrerò nei motivi, ma hai ragione.

Nella mia esperienza, ai PHB manca la parte del cervello necessaria per capire perché il fail veloce ha merito e la "robustezza" come definita da "fare-da-mangiare-errori-se-necessario" è una cattiva idea . È senza speranza. Semplicemente non hanno l'hardware per farlo. Tendono a dire le cose "ok, fai un buon punto, ma per quanto riguarda l'utente" - è solo la loro versione di think of the children e segnala la fine di una conversione con me ogni volta che viene richiamato.

Il mio consiglio è di mantenere la posizione. Eternamente.

Answer 6

Condivido la preferenza/principio "fail fast". Non pensate che questo sia un conflitto di principi, è più un conflitto di comprensione. La tua controparte ha alcuni requisiti inespressi ("non mostrare all'utente un brutto momento") che implica alcuni requisiti mancati. Non hai avuto la possibilità di pensare a/implementare questo requisito in anticipo, quindi il requisito ha lasciato l'amaro in bocca. Dimentica questo punto di vista, ri-affrontalo come un nuovo progetto con un requisito fisso su cui puoi lavorare.

Forse il miglior risultato è quello di dare un messaggio di errore come hai visualizzato. Ma sembra che tu l'abbia implementato prima di avere un buy-in dalla tua controparte, quando hanno avuto la possibilità di accettarlo. Una comunicazione precedente su quello che stavi facendo avrebbe potuto affrontare qualcosa del genere.

Fai attenzione nel modo in cui prevedi le idee. Riferendosi costantemente agli altri sistemi "troppo complessi e fragili" potrebbe sfregare le persone nel modo sbagliato. Esprimi semplicemente i sistemi sono nuovi per te e impiegano più tempo per capire. Metti il ​​tempo per comprenderli, in modo da non ridurre le aspettative della tua capacità.

Answer 7

In genere dipende dalla classe di errore che si ottiene. Se il modo in cui il sistema si sta rompendo significa che puoi andare avanti senza fornire dati cattivi a nessun'altra parte del sistema, dovresti fare tutto ciò che è in tuo potere per lavorare con qualsiasi input dato.

A mio parere, sebbene la purezza dei dati superi i sistemi operativi, non è possibile consentire a dati non validi di propagarsi altrove e danneggiare altri sistemi.Nella misura in cui puoi massaggiare i dati per essere corretti e continuare così, dovresti farlo sulla base della teoria che i dati sono sicuri e devi mantenere il sistema in esecuzione ...

Mi piace pensare alle cose in termini di flussi di dati. Passare cattivi dati è inquinare tutto il flusso, e questo è male perché, proprio come l'inquinamento reale, una goccia può rovinare un intero fiume di dati (se un elemento è cattivo, che altro puoi fidarti?). Ma altrettanto male sta bloccando il flusso, lasciando passare nulla perché hai individuato qualcosa che potresti facilmente rimuovere. Filtralo e se tutti in ogni fase sono anche filtri, ottieni chiari dati puliti dall'altra parte anche se alcune impurità sono iniziate nel mezzo.

Answer 8

La domanda dai vostri coetanei è: "perché non risolvere il problema"

Lei dice che è possibile per voi rilevare i dati non validi, e segnalare un errore per l'utente. Questo è l'approccio normale: una volta che sai che i dati che arrivano alle tue funzioni sono sbagliati, dovresti fallire velocemente (e questa è la raccomandazione delle altre risposte che ho letto qui).

Tuttavia, la domanda non specifica il dominio in cui il software è operativo. Se sai che i dati in arrivo sono errati, è possibile richiedere nuovamente tali dati? È effettivamente possibile recuperare dalla situazione?

Ho menzionato che il "dominio" qui è importante. Quindi, se hai un'app che visualizza i dati video in streaming, ad esempio, e forse il segnale wireless è debole, quindi il flusso è corrotto, se il sistema "fallisce velocemente" e visualizza un messaggio di errore? O dovrebbe essere visualizzata un'immagine più povera e un tentativo di riconnessione fatto se necessario, a seconda dell'entità del problema?

A seconda del dominio, potrebbe essere possibile rilevare dati non validi e inoltrare una seconda richiesta per i dati senza arrecare disturbo all'utente. (Questo è chiaramente pertinente solo nei casi in cui ci si aspetta che i dati siano migliori la seconda volta, ma si dice che i problemi che si verificano sono intermittenti e possibili concorrenti) ...

Quindi, fail-fast è buono, ed è sicuramente qualcosa che dovresti fare se non puoi recuperare. E non dovresti assolutamente propagare dati cattivi. Ma se riesci a recuperare, cosa che in alcuni domini puoi fare, fallire subito non è necessariamente la cosa migliore da fare.