Domanda:
Come comportarsi con un collega che mi ha incolpato del bug che era colpa sua
Ryan
2018-03-09 10:38:41 UTC
view on stackexchange narkive permalink

Sono relativamente nuovo in un lavoro, ma mi sono affermato come il "ragazzo" quando si tratta di un determinato servizio web che utilizziamo. Il nostro sito web si integra con il servizio. In realtà non lavoro sul sito, solo con il servizio.

Oggi abbiamo avuto un problema di arresto dello spettacolo che ha impedito agli utenti del sito di utilizzare il servizio. Naturalmente sono stato chiamato per aiutare, ma uno degli sviluppatori del sito è rimasto molto soddisfatto di me personalmente, insinuando che non stavo facendo il mio lavoro e accusandomi di scarsa comunicazione. Più tardi in una teleconferenza con almeno altre 8 persone, mi ha chiamato in modo passivo-aggressivo per non aver risolto il problema.

Dopo una lunga giornata, lavorando fino a tardi e da casa, ho finalmente determinato la radice del problema non essere nel servizio, ma nel codice del sito e nello specifico nel codice che ha scritto lo sviluppatore snippy.

TL; DR: il ragazzo che mi puntava il dito era in effetti la causa del problema

Sono generalmente una persona facile e non ho bisogno di rimproverare questo ragazzo; tuttavia, spero in alcuni suggerimenti su come esprimergli con tatto che preferirei che fosse assolutamente sicuro al 100% che non è il suo codice prima che riprenda quel tono con me.

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (https://chat.stackexchange.com/rooms/74530/discussion-on-question-by-ryan-how-to-deal-with-a-coworker-who-blamed-io-per-il).
Undici risposte:
Edgar
2018-03-09 12:15:02 UTC
view on stackexchange narkive permalink

Basta inviare un'e-mail a tutte le persone coinvolte dicendo che, dopo l'orario di lavoro, hai trovato (e corretto) il bug. "È così e così in AB." Forse con un collegamento a qualcosa. Non menzionare nessuna persona.

Dovrebbe essere sufficiente. Non devi puntare il dito contro nessuno.

Gli altri lo esamineranno e presto scopriranno chi era / è responsabile di quel bug e la prossima volta ci penseranno due volte prima di scherzare con te.

Lo farei anche supponendo che sia stato un incidente una tantum.Se fa parte di un modello, potrebbe essere giustificata un'escalation difensiva.Per ora mi limito a tenere pronte le note di quello che è successo in modo che se questo accade un paio di volte posso compilare un rapporto abbastanza dannoso di quanto tempo stai spendendo per ripulire questo casino.
D'accordo con questo.Fatti vedere come il ragazzo che viene sistemato e lascia che gli altri giochino al gioco della colpa se lo desiderano: invia un'e-mail neutra spiegando dove si trovava il problema e chi conosce il sistema può capire chi l'ha causato, non è necessarioper chiarire questo punto
D'accordo anche.Dalla mia esperienza, il ragazzo più interessato a trovare qualcuno da incolpare che a risolvere il problema di solito è quello da incolpare.Supponendo che i tuoi manager non siano stupidi, sanno già chi ha sbagliato.
"Poiché gli altri esamineranno questo" dipende, molte persone, in particolare i livelli superiori, non esaminano problemi risolti.
C'è un detto nel mondo degli affari: "Possiedi l'errore".Anche se in realtà non era tuo, hai * fatto * lo sforzo di risolverlo, quindi dovresti assolutamente possedere il tempo e gli sforzi extra che hai messo per risolverlo. Non c'è bisogno di puntare il dito contro questo ragazzo per aver commesso l'errore in primo luogo - ammetti solo il fatto che te ne sei occupato tu.
Sono d'accordo con @DonQuiKong.Altri possono o non possono preoccuparsi di esaminarlo.Ma sembra che menzionare dove si trovava il bug probabilmente renderà chiaro che è stato qualcosa che ha fatto lui, non tu.Ma sono anche d'accordo con gli altri commenti sul fatto che la direzione / le parti interessate rimarranno più colpite dal fatto che hai dedicato del tempo extra per risolverlo piuttosto che dalla colpa di chi è stato.
Per soddisfare il bisogno di vendetta farei scorrere un "scusa per tutto il blocco, il motivo per cui mi ci è voluto così tanto tempo è che il bug non era nel codice su cui sto lavorando ma si è rivelato essere in quest'altra parte".
Bella domanda, e questa risposta è perfetta.Vorrei solo aggiungere qualche centesimo.Nella mia esperienza, quando le persone diventano così aggressive di solito indica che sono in colpa.Quindi tutte le persone che hanno assistito a questo sanno che è una forte possibilità, quindi inviare una comunicazione su quale fosse la causa principale, come è stata risolta e come sarà prevenuta in futuro senza mirare alla sua testa sarebbe appropriato e tuttitrarrebbe la giusta conclusione e adatterebbe le loro percezioni di conseguenza.
Tutto ciò è stato di grande aiuto, grazie a tutti per essere intervenuti. Penso di essere stato un po 'agitato per l'incidente, quindi alcune risposte equilibrate sono proprio ciò di cui avevo bisogno.Ho fatto esattamente ciò che è stato suggerito in questa risposta (che è ripreso in molte altre risposte, mi dispiace di poter approvare solo una come "corretta"): ho inviato un'e-mail con il collegamento alla mia richiesta di pull, quindi le prove sono lìper tutti da vedere.Mi sento bene nel non puntare il dito e nel lasciare che gli altri, se vogliono, capiscano dove risiede il vero problema.Grazie ancora.
@Džuris Se si utilizza CV, finirei con "[...] lavorando su; è stato introdotto nella revisione # 9987".
Non puoi lasciarlo passare senza sottolineare che non era il tuo codice ma il suo codice.Fare questo senza puntare il dito contro chi era responsabile lascerà alle persone una cattiva impressione di te.Il mio commento sarebbe stato diverso se l'altro ragazzo non avesse messo in dubbio le tue capacità.
Nessuno lo esaminerà.Qualcuno verrà assegnato per risolverlo, ma è così.Al manager non interesserà da dove proviene e probabilmente penserebbe anche che tu ne fossi responsabile.Anche se è tecnicamente valido, non importa a lui chi ha causato il problema, solo che è stato risolto. Il meglio che puoi fare è cercare di rendere evidente chi era responsabile, ma senza usare esplicitamente il suo nome. Un'altra opzione è rispondere al comportamento della persona come una questione centrale e quindi fare riferimento a come ti ha incolpato per qualcosa, ma in realtà è stato lui la causa di ciò.
Comunque vorrei fare una parola tranquilla con il collega e fargli sapere che non è bello iniziare a puntare il dito e insultarmi di fronte alla squadra, e che la prossima volta che lo farà può aspettarsi di avere un problema serio alle mani.
Quello che farei è includere "è stato introdotto nella versione # 123 del sito web" e collegare quel testo all'interfaccia web del controllo del codice sorgente che indica chiaramente chi lo ha commesso.Se hai una simile interfaccia web, ovviamente.
@DonQuiKong Verranno assolutamente esaminati se si tratta di un difetto che blocca lo spettacolo.Le aziende probabilmente ordineranno almeno un rapporto.
@PieterB Puoi dire che non era il tuo codice senza indicare esplicitamente di chi fosse il codice.Il suggerimento di Josef è come lo farei, personalmente (cioè, annota e collega nel bug tracker quale revisione di quale codice ha causato il problema. - Inoltre, questa è solo una buona pratica per scopi di documentazione, comunque, anche se fosse stato codicehai scritto tu stesso.)
Se questa persona (o qualcun altro) si comporta di nuovo allo stesso modo in una riunione, potresti semplicemente dire che aggiornerai tutti non appena avrai trovato e risolto il problema.Ciò, ovviamente, significa che potresti dover ammettere pubblicamente gli errori che hai commesso, ma non dovrebbe essere un problema.
Per renderlo davvero chiaro, anche al più pigro dei destinatari, includi qualcosa sull'effetto di "questo bug è stato introdotto nel commit r456, che ha ".Il tizio che fa le false accuse saprà che è il suo codice nel diff, e chiunque altro voglia scavare più a fondo può facilmente controllare il sistema di controllo della versione e vedere chi ha effettuato il commit.
user44108
2018-03-09 12:23:45 UTC
view on stackexchange narkive permalink

Evita il gioco della colpa

Ci saranno sempre problemi, si verificano errori, si verificano circostanze, il che significa che il servizio X non è più soddisfatto del servizio Y.

Ciò di cui tutti hanno bisogno concentrarsi sulla risoluzione del problema senza lasciarsi coinvolgere dal gioco della colpa. Lascia che l'esperto in materia esamini e diagnostichi il problema e risolva le cose da lì.

Il problema non è (ufficialmente) con qualcun altro: è un problema con il servizio Y che ha il proprio esperto in materia per risolvere il problema.

Dopodiché, c'è una "lezione imparata" per cercare di capire cosa ha causato il problema.

Non "chi". Questa è la cosa fondamentale qui. Se le persone vogliono prendersi la colpa, questa è la cosa onorevole da fare.

In questo caso, non vendicarti, non lasciarti trascinare nel gioco della colpa, sii grato che il problema è stato identificato e risolto.

Stai suggerendo di ignorare completamente il dito puntato o di dire all'altro ragazzo di non farlo per favore?
Questo è il problema con il meme "Evita il gioco della colpa".Quello che di solito succede è che una persona incolpa qualcuno e poi quando qualcuno dice "ehi, non sono io", la prima persona torna e dice "non mettiamoci nel gioco della colpa".Molte persone che negano profondamente con la lavagna a fogli mobili dicono cose carine e volgari sulla comunicazione e sulle "lezioni apprese" e altro, ma la realtà è che dovresti fare la cosa giusta (senza incolpare gli altri per i tuoi errori) * perché * è la cosa giustacosa (non aspettandoti una ricompensa), e succhialo come puoi quando gli altri non si comportano perché il lavoro ti paga.
@user6697063 Ho capito il tuo punto qui.ma la colpa del gioco è roba da parco giochi piuttosto immatura.Si è tentati di incolpare le persone per gli errori che si verificano, ma la cosa matura è concentrarsi sul problema stesso e imparare da qualunque errore lo abbia causato.Chi ha causato il problema dovrebbe essere abbastanza maturo da ammetterlo (anche solo a se stesso) e andare avanti da lì.Il mio attuale team non segue la cultura della colpa, dobbiamo solo andare avanti e sistemare le cose.
@Snow Dici che è roba piuttosto immatura, ma se il manager di OP si blocca nella testa su cui non si può fare affidamento su OP, ciò influisce sulla loro carriera.È una bella regola in generale, ma se le tue capacità vengono messe in discussione pubblicamente penso che ci debba essere una sorta di respingimento, altrimenti potrebbe diventare un problema ricorrente.
Un modo diverso di inquadrarlo è ciò che "incolpare" è il * processo *.O * più * persone sono "da incolpare", oppure hai un processo in cui un errore di una persona sola può causare un problema serio nella produzione, nel qual caso è "colpa" l'intera squadra.Incolpare un individuo per un errore non gli impedirà (o chiunque altro) di commettere un altro errore in futuro.Capire come migliorare il processo in modo che sia più difficile che gli inevitabili errori diventino fallimenti della produzione, tuttavia, è sia un dialogo costruttivo che di valore aziendale.
@snow Il mio approccio abituale, se vengo incolpato da persone che hanno l'abitudine di puntare il dito, è solo quello di dire dove penso sia la colpa, lasciare che dicano "non facciamo il gioco della colpa", e poi andiamo avanti con la vita.In questo modo altre persone possono decidere.Il problema di lasciarlo passare è che puoi finire per ottenere una reputazione di zerbino tra le persone che cercano di far passare i propri errori e, quando raggiunge la massa critica, le persone che non sanno cosa sta succedendo presumono che un pezzo di lavoro sia scadentequalità anche se non ti conoscono, e diventa tradizione.Di solito una sfida iniziale è sufficiente per fermare quella spirale.
@DerekElkins Dopo anni di lavoro con qualcuno che diceva questo, * no *.A volte * è * colpa di una persona.Perché specialmente nel software, ci sono grandi difetti di progettazione, solo semplici stupide righe di codice e una comprensione completa e totalmente sbagliata del codice che hai scritto.Anche se non abbiamo bisogno di vergogna pubblica di alcun tipo, devono riconoscere (almeno mentalmente) che hanno sbagliato e imparare da esso.Nessun processo può risolvere tutto.A volte devi semplicemente avere persone competenti e le persone non diventano competenti senza assumersi la responsabilità delle loro decisioni sbagliate.
@Snow è bello se funziona per te, ma non funziona ovunque.Nella situazione di OP, viene chiamato pubblicamente di fronte a persone che non fanno parte della squadra e viene incolpato.Se lui / lei torna con un post-mortem dalle parole neutre, un risultato comune è che le persone non strettamente coinvolte (come un manager di alto livello) avranno l'idea di OP incasinata ma almeno la risolveranno.
Ti biasimo @Snow
I giochi di colpa distruggono il morale e portano a una cultura tossica.Non giocarci mai.
Akshay Arora
2018-03-09 16:41:44 UTC
view on stackexchange narkive permalink

Alcune persone hanno la tendenza a dare la colpa agli altri in modo aggressivo per distogliere l'attenzione da se stesse. Dato che sei anche relativamente nuovo, deve essere stato molto conveniente per lui fare quello che ha fatto.

Ecco il mio consiglio. Scrivi una e-mail, descrivi qual era il problema, come hai raggiunto la causa principale, qual è stata l'eventuale soluzione e come può essere prevenuta in futuro. Includi tutte le parti interessate in questa e-mail.

Alla fine di questa e-mail, scrivi qualcosa su queste righe,

XYZ,

Puoi per favore aggiungere questi passaggi nella documentazione appropriata o nel documento sulle procedure operative standard per questo pezzo di codice?

In questo modo "non gli stai puntando il dito", ma lo stai chiamando esplicitamente che è il proprietario di questo pezzo di codice e quindi responsabile di esso. Il richiamo è importante perché non tutti (specialmente i dirigenti superiori) apriranno i link della base di codice per vedere di chi è stato il commit.

Un po 'duro, ma se lo merita.

La migliore risposta fino ad ora IMO.L'idea di chiedere la documentazione è abbastanza buona.
Mi piace l'idea di aggiungere una nota per "XYZ ....."
Nella maggior parte dei posti in cui ho lavorato, qualcuno guarda davvero il codice, specialmente se ci sono stati problemi / interruzioni degli utenti effettivi.In caso contrario, tenderebbero a chiedere a qualcuno che ha.Non penso che sia necessario chiamare, e preferirei non farlo, a meno che non si ripresenti e non mi venga fastidio.
Guy Schalnat
2018-03-09 18:58:32 UTC
view on stackexchange narkive permalink

Ho costruito una carriera senza giocare al gioco della colpa, ma la verità è che gli umani ascoltano la voce più alta. Tuttavia, se ti impegni a difenderti, ti tirerà giù al suo livello e ti batterà con l'esperienza.

Se riesci a trovarne uno, hai bisogno di un campione. Idealmente, questo dovrebbe essere il tuo manager, ma a volte è un altro sviluppatore molto rispettato. Andranno a battere per farti tacere il forte. Tutto quello che devi fare è avere una discussione privata con loro sui fatti (non la colpa) di ciò che hai fatto per risolvere il problema e su come vorrebbero che tu procedessi in modo che, la prossima volta che qualcosa non va con il servizio, il problema può essere trovato e risolto più velocemente. Ciò può comportare la scrittura di una piccola utility di test che collauda direttamente il servizio (senza utilizzare il codice degli altri sviluppatori), o alcuni log o qualcosa del genere, in modo che il problema "noi contro loro" possa essere determinato molto rapidamente. Se sanno chi è effettivamente la colpa, possono cancellare il tuo nome senza che tu entri in conflitto diretto con quello rumoroso.

Mi sono sempre fatto in quattro per evitare di mettere in difesa altri sviluppatori. Ho detto cose come "Ho problemi a duplicare il problema, puoi farmi sapere quali chiamate stai facendo al servizio e cosa stai ricevendo in modo che io possa testare correttamente il servizio"? Se lo sviluppatore si preoccupa di darti le tracce del registro delle chiamate e delle risposte effettive, chiedi cosa si aspettavano di ricevere. Tuttavia, la maggior parte delle volte, lo sviluppatore ti mostrerà semplicemente il suo codice. In tal caso, a volte puoi individuare il problema. Anche se lo fai, continua a non chiamarli. Devono trovare il problema da soli. Invitali a eseguire il codice tramite un debugger e chiedi innocentemente cosa contiene una determinata variabile in una determinata riga di codice. Potrei continuare, ma hai capito.

Il miglior consiglio qui.Gestire il codice è molto simile a gestire i problemi con i post qui su SE;se lasci che le cose si personalizzino, tutti smettono di ascoltare gli altri.
Michael Kay
2018-03-09 22:52:11 UTC
view on stackexchange narkive permalink

È una tradizione molto sottile nel settore IT (e in alcuni altri, come l'aviazione) che quando qualcuno trova un problema, tutti lavorano insieme per trovare una soluzione e idealmente per trovare la causa principale in modo che i processi possano essere migliorati, ma nessuno ottiene la colpa personale o subisce sanzioni per aver commesso l'errore. Il risultato è che le persone sono aperte e oneste riguardo ai propri errori, invece di cercare di coprirli, il che è a vantaggio di tutti.

Sembra che nel tuo negozio ci siano persone che non hanno acquistato a questa cultura, e questo è qualcosa che richiede l'attenzione della direzione.

OP dice che c'è stata una chiamata di 8 persone, con 2 o più sviluppatori presenti.Uno degli argomenti discussi è stata la scarsa comunicazione, tutto questo mentre la produzione era inattiva.Solo la * sera * OP è stato in grado di analizzare efficacemente il problema.La colpa del gioco non è il problema più grave di questa "cultura".
LVDV
2018-03-09 18:05:33 UTC
view on stackexchange narkive permalink

Credo che dovresti parlare con il tuo manager su come vengono gestiti i problemi, in particolare i problemi prioritari che influiscono sull'esperienza dell'utente.

In questo caso hai 2 sistemi che comunicano tra loro e improvvisamente la comunicazione smette di funzionare. Quando la comunicazione fallisce, è importante che entrambe le parti guardino entrambi i sistemi. Tutti si concentrano sul tuo servizio, portandoli a non indagare sulle cose alla loro fine. La più grande perdita di tempo nella risoluzione di un problema è cercare di scoprire cosa c'è che non va in una parte di esso che funziona effettivamente come dovrebbe .

Queste sono, tuttavia, esperienze di apprendimento. Scommetto che ora sai perfettamente come risolvere i problemi del tuo servizio. Prova a impostare un piano di risoluzione dei problemi in base alla tua esperienza e fai uno dei primi passaggi per assicurarti che sia effettivamente il tuo servizio che non funziona ("Il servizio funziona quando viene chiamato da un'altra pagina?", "Il servizio non funziona parzialmente o interamente?"). Sei IL ragazzo del servizio web, puoi avere un po 'di fiducia nel tuo lavoro.

Cerca di lasciar andare il fatto che in realtà è stato il suo codice a fallire. Cercare di chiamarlo per questo è un po 'meschino. Non avrebbe dovuto concentrarsi così tanto su di te dall'inizio. Consideralo un problema generale all'interno dell'azienda con la risoluzione di un problema e gestiscilo come tale con il tuo manager. Inoltre non sai se fosse effettivamente il suo codice, avrebbe anche potuto copiarlo da un'altra sezione scritta da un collega.

Sì, in un mondo ideale questo servizio web sarebbe coperto da una suite di test e l'esecuzione di quella suite sarebbe il tuo primo punto di riferimento.Se tutti i test vengono superati, allora stai osservando (a) errore del client, (b) errore del servizio non rilevato dai test, ovvero un errore del test, (c) servizio che funziona come previsto ma non come previsto dal client, ovvero, un errore di documentazione.
È una buona scelta, dovrò esaminare una sorta di banco di prova per il servizio.È un servizio piuttosto popolare e robusto, quindi onestamente non penso che sia mai un problema di bug con loro, più di una cosa configurata correttamente.Indipendentemente da ciò, è il mio dominio, quindi sarebbe fantastico coprire le mie basi per la prossima volta che accadrà.Ma il lato positivo è che ho imparato di più su quel dominio, insieme a un mucchio di codice "AB" che interagisce con il mio dominio, quindi sto meglio per l'esperienza.
Copiare il codice che non capisci è inappropriato, anche se non presenta bug.E se è nello stesso progetto, copiarlo invece di chiamarlo è inappropriato.
William Jockusch
2018-03-11 17:54:45 UTC
view on stackexchange narkive permalink

Penso che il suggerimento di parlare con il tuo manager sia buono. Il tuo manager deve sapere che sei stato incolpato ingiustamente.

Ma oltre a questo, sei sottoposto a test. Il tuo istinto iniziale è giusto; devi rispondere, o peggiorerà. Gli inviavo un'e-mail direttamente e gli facevo sapere che il problema era nel suo codice, e che per questa volta non l'hai detto a nessuno tranne che al tuo manager, a cui dovevi dire per proteggerti. Infine fagli sapere che se lo fa di nuovo, diventerai pubblico.

Questo aumenterà solo il problema, non sono d'accordo con il tuo consiglio
Un attacco privato è ancora un attacco e sì, aggraverà la situazione.L'azione correttiva dovrebbe seguire la catena di comando.
Più di una "risposta proporzionata".Ho avuto situazioni come questa;se uno non risponde, tende a peggiorare.La cosa della catena di comando potrebbe funzionare.Forse o forse no.Quello che posso dire è che per esperienza personale, l'ho visto fallire due volte e avere successo una volta.Il guaio è che in attesa di scoprirlo, le cose possono peggiorare un po '.
Korthalion
2018-03-12 15:27:31 UTC
view on stackexchange narkive permalink

In qualità di tester di software, ho familiarità con questa situazione. E anche come tester del software, perché questo bug non è stato rilevato durante i test? Suppongo che tu sia uno sviluppatore?

Sì, fa schifo che tu sia stato incolpato dalla persona che ha causato il problema. Tuttavia, questo NON è ciò che interesserà all'azienda. Tutto quello che vogliono è una risoluzione in cui non ci siano più ostacoli allo spettacolo sul sito live.

Aspetterei fino alla prossima teleconferenza se li hai regolarmente e menzionerei che hai analizzato la causa principale del problema e dichiarare oggettivamente i risultati. Se ti viene chiesto chi ha scritto quel codice, rispondi chi era, altrimenti non puntare il dito contro il tizio che l'ha fatto. Dovresti essere più maturo / professionale di così e riceverai molto più rispetto se gestisci la situazione in questo modo.

Come risoluzione per impedire che ciò accada di nuovo, testare le query su come è scivolato attraverso in modo non accusatorio e collabora con loro per implementare un nuovo passaggio o test che avrebbe individuato il problema.

Infine, segnala tutto questo al tuo manager. I difetti dello show stopper sono un grosso problema e anche i suoi superiori gli avranno il fiato sul collo.

Paddy
2018-03-14 15:25:16 UTC
view on stackexchange narkive permalink

Sono un po 'in ritardo sulla domanda qui, ma oltre al consiglio molto valido nella risposta di Edgar, c'è una seconda parte.

Se invii una comunicazione che hai trovato il problema e nota dove è stato risolto, quindi gli altri sviluppatori probabilmente sapranno dove si trova il problema (questo è positivo), ma la direzione probabilmente no.

In questo modo significa che hai fatto a questo ragazzo un favore - ti ha chiamato pubblicamente, hai trovato il problema, lo hai risolto e non lo hai lasciato cadere con la direzione. Costruire una fiducia in questo modo con i tuoi colleghi ti aiuterà a lungo termine.


Piccola nota a margine: questo ovviamente dipende leggermente dalla natura del difetto che trovi nel loro lavoro . Se quello che trovi è così gravemente sbagliato da indicare incompetenza da parte loro, potresti comunicarlo in silenzio al tuo manager: loro vorranno saperlo e anche tu stai creando fiducia con loro.

Se non lo esponi, altri probabilmente lo faranno.A meno che non siano tutti i suoi "amici", nel qual caso tu sei la storia nonostante la tua innocenza.
Kevin Olree
2018-03-11 09:17:34 UTC
view on stackexchange narkive permalink

Ti suggerisco di dormirci sopra prima di rispondere agli aspetti personali della situazione. Se risolvi il problema e riesci a far funzionare di nuovo le cose, sei ancora "l'uomo". Dopo esserti riposato un po 'sarà più facile essere gentili.

André Werlang
2019-03-07 05:49:19 UTC
view on stackexchange narkive permalink

Anche se il problema principale è stato già affrontato a lungo in altri awswers - l'altro tizio che ti molesta - vorrei farti notare un'altra prospettiva.

La correzione è stata fatta nel codice di proprietà dell'altro ragazzo , tuttavia il più delle volte il servizio avrebbe potuto evitare un problema più grande essendo più prudente nel gestire le richieste dei clienti. Convalida gli input? Segnala errori di runtime? Esiste un ambiente di test (questo vale anche per il consumatore)? A volte un problema nel servizio aspettava solo di emergere, quindi direi che solo perché è stata eseguita una correzione in un punto non significa che sia l'intera storia. Inoltre, per problemi come questo, c'è più di un semplice codice. C'è anche un processo.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...