Domanda:
Ho commesso un possibile errore su un progetto live al lavoro, come gestire questo pasticcio?
joezlja
2012-04-23 08:49:43 UTC
view on stackexchange narkive permalink

Sono uno sviluppatore di software che ha appena iniziato in questa azienda. Sono passate quasi tre settimane.

Venerdì, quando stavo per lasciare il lavoro, un collega mi ha fermato e mi ha detto di apportare modifiche al codice già funzionante.

Il fatto che questo progetto live sarebbe stato utilizzato durante il fine settimana da un cliente reale in un ambiente di produzione non mi era stato reso noto.

Di solito il QA testa tutto, ma stranamente, nessun QA è stato notificato e nessun test funzionale è stato eseguito .

Ho ricevuto una telefonata questa mattina dal project manager che sembra in preda al panico e mi chiede quali modifiche ho fatto. Ho anche parlato con uno sviluppatore senior e lui mi sta urlando che non l'ho testato o scritto completamente e che deve apportare le correzioni.

Quindi parlo di nuovo con il project manager e lui dice che lo faremo hanno tutti un incontro.

Se avessi saputo che sarebbe stato eseguito domenica dal vivo, avrei testato il codice. Credo di essere in colpa qui e probabilmente dovrei ammetterlo. Ma mi sento un po 'arrabbiato per aver ascoltato ciecamente un collega senza consultare il project manager o lo sviluppatore senior. Se le modifiche suggerite dal collega non fossero state apportate, tutto avrebbe funzionato perfettamente. Aveva bisogno di quelle modifiche in modo da poterlo utilizzare nel suo altro progetto. Non c'era nessuna cattiva intenzione, ma nel complesso non è stato trasmesso lo stesso livello di consapevolezza o urgenza.

Ora temo di essere licenziato perché non lavoro da molto in questa azienda. Lunedì cosa devo fare?

Questa è la prima volta che lavoro come sviluppatore e mentre cercavo disperatamente di non commettere errori critici, è successo. Ora non so come affrontare questa situazione generale.

come è andata la riunione? Sarebbe una nota interessante alla domanda!
e poi che è successo?
Hai distribuito il codice in produzione o hai semplicemente eseguito il commit delle modifiche alla libreria? Qual è la politica aziendale sull'impegno nella biblioteca? In qualsiasi azienda per cui ho lavorato, i programmatori inviano regolarmente codice alla libreria che non è pronto per la produzione. Nel mio attuale lavoro, ci impegniamo per la libreria, quindi distribuiamo da lì in una regione di sviluppo dove i nostri test di QA, quando sono felici, andiamo in una regione in cui il client esegue i test, e infine ci distribuiamo alla produzione. Spetta alla persona responsabile della distribuzione sapere cosa deve essere distribuito alla produzione, non alla persona che ha eseguito il commit del codice.
Il modo in cui uno sviluppatore junior è stato in grado di inserire le modifiche al codice nella produzione è sconcertante. Perché non esiste un sistema di revisione del codice con revisori critici, fasi di gating nella pipeline di sviluppo, autorizzazioni, ecc.?
A giudicare dai commenti, la questione sembra essere un po 'finita ora, ma se voi ragazzi progettate incontri di tipo "Restrospettivo" o "Lezioni apprese", questo sarebbe un buon argomento da sollevare!
@joezlja: Sto morendo di curiosità qui.Cosa è successo dopo?
Otto risposte:
#1
+39
weronika
2012-04-23 09:18:16 UTC
view on stackexchange narkive permalink

Sicuramente ammetti il ​​tuo errore : questa è chiaramente colpa tua, dal momento che non hai fatto i test e il fatto che anche altre persone possano essere state colpevoli non è una scusa. (E in ogni caso, forse non l'hanno fatto - forse avresti dovuto sapere che il sistema sarebbe stato attivo domenica e semplicemente non hai controllato qualche risorsa importante per scoprirlo!)

Tuttavia, l'altro passaggio importante è chiarire che questo non accadrà più , non promettendo che non succederà, ma spiegando perché è successo e quali misure intraprenderai per prevenirlo in il futuro e, se necessario (cosa che sembra), chiedere aiuto . Sembra che ti mancassero alcune informazioni importanti: chiedi linee guida su come gestire le richieste di modifiche dell'ultimo minuto, dove controllare per assicurarti cosa sarebbe stato pubblicato quando, ecc. Ancora una volta, il punto di questo non è mettere la colpa a chiunque altro, ma per capire esattamente cosa hai fatto di sbagliato o cosa avresti dovuto sapere e tutte le cose che puoi fare per prendere decisioni migliori in futuro. Si spera che diventi chiaro che il tuo errore è dovuto a qualcosa che è facilmente risolvibile e tutti si sentiranno ragionevolmente sicuri che non accadrà più.

Il fatto che tu sia nuovo al lavoro potrebbe giocare a tuo favore qui: ci si aspetta che le nuove persone commettano degli errori e migliorino rapidamente . Se, dopo aver lavorato lì per un anno, non ne sapessi ancora abbastanza per evitare di causare questo tipo di problema, sarebbe chiaramente un segno di un problema significativo, ma dal momento che non sei stato lì abbastanza a lungo per essere molto familiare con come funziona tutto, le persone potrebbero pensare che questo sia stato un errore da principianti che è improbabile che si ripeta.

Ancora una volta - questo è davvero il punto più importante qui - durante la riunione, rendi ovvio che la tua priorità è impedire che il problema si ripresenti, non evitare la colpa , e potrebbero decidere che l'approccio rende sei un dipendente abbastanza bravo da mantenere.

appena registrato per aggiungere questo commento: Chiediti "perché?" 5 volte. ti aiuterà a trovare le risposte alle domande che molto probabilmente ti verranno poste (Perché il sistema si è rotto? Perché ho commesso codice non testato. Perché hai commesso codice non testato? Perché io ... Continua finché non trovi una risposta correlata a un processo che non sei riuscito a seguire piuttosto che a un errore personale che hai fatto ("non ero abbastanza attento" non è una buona causa principale, "non ho seguito correttamente il" processo di revisione del codice-test-commit # QA101 "è meglio). Questo è un buon punto di partenza da cui risolvere i problemi.
il "perché" finale? dovrebbe portare a una risposta del tipo "non ho chiesto conferma scritta al mio supervisore" o qualsiasi altra cosa che coinvolga almeno una parte del sistema aziendale o della gerarchia (comunque, non è colpa loro) Cerca di non preoccuparti troppo, se licenziano un nuovo impiegato al primo errore ci sono molte possibilità che non sia un bel posto dove lavorare 40 ore a settimana
+1 per concentrarti sull'affrontare il problema piuttosto che affrontare la colpa.
@STTLCU - sì, esattamente questo: finire con una ragione che è un fallimento di un processo, che si può ragionevolmente dire che non accadrà più. Naturalmente, potrebbero esserci più risposte ad alcune delle domande sul "perché" e più di un fallimento del processo - importante notare anche tutte quelle.
+1 per "Ammettere l'errore", analizzare la catena di eventi che lo hanno preceduto e adottare misure per garantire che non accada mai più ** a livello aziendale ** (ovvero assicurati che il "collega che ti chiede di cambiare codice di produzione alle 5 di venerdì "cosa non succede mai più - a *** chiunque ***)
@voretaq7 - Vero, ma in questo caso mi concentrerei sul lato "cosa posso fare per assicurarmi di seguire la procedura corretta" piuttosto che provare a cambiare la procedura, cosa che potrebbe non essere presa bene da un nuovo dipendente. Tuttavia, si spera che l'analisi del problema faccia rilevare al resto del team eventuali problemi con la procedura e che assumano l'iniziativa di affrontarli.
-1 per presumere che una società che non dispone di controlli per impedire che il codice rookie arrivi alla produzione ha una risorsa che l'OP avrebbe potuto controllare per sapere che il codice sarebbe stato rilasciato.
@AmyBlankenship Non pensavo, ho detto * forse *. È possibile che ci fosse qualcosa.
#2
+31
maple_shaft
2012-04-23 17:02:52 UTC
view on stackexchange narkive permalink

Sei colpevole qui, ma direi che non è interamente colpa tua.

Ovviamente come sviluppatore dovresti sempre testare il tuo codice prima di fare il check-in e MAI fare affidamento sul QA come piano di test. Questo è ovvio.

D'altra parte, sono fermamente convinto che anche qui dovrebbero prendersi un po 'di colpa:

  1. Non ti hanno comunicato quando il il codice stava per essere distribuito su live / produzione / client.

  2. Un peer non ha esaminato le modifiche al codice prima di passare attraverso il processo di QA. Questa dovrebbe essere una politica obbligatoria per il tuo team, specialmente per gli sviluppatori junior e nuovi del team.

  3. Il loro team QA avrebbe dovuto essere più accurato prima di autorizzare ciecamente il rilascio del software alla produzione .

Non lasciare che ti attribuiscano tutta la colpa, ammetti i tuoi errori ma sottolinea gli altri punti di fallimento che hanno portato alla situazione. Se il tuo manager e la tua azienda sono un posto utile in cui lavorare, saranno più preoccupati di risolvere il problema che punire con la colpa.

Tutti noi commettiamo errori, ognuno di noi.

Ho ammesso di non aver testato il codice all'ultimo minuto perché stavo per partire è stata colpa mia e mancanza di attenzione ai dettagli. Normalmente ricevo sempre i biglietti su TRAC dal team QA e dal momento che non è mai successo, non pensavo fosse possibile che questo progetto venisse pubblicato in primo luogo. Mi è stato anche detto che in effetti nessun QA è stato assegnato a questo progetto dall'inizio (!) Per il mio shock e che avrebbero dovuto dirmelo. Lo sviluppatore senior ha rilevato questo progetto ora e non è stato segnalato alcun danno reale, ma mi dispiace ancora che lo sviluppatore senior debba riprenderlo.
@joezlja hai fatto la cosa giusta riconoscendo il tuo errore, ma sembra che abbiano alcuni problemi che devono risolvere. Non sentirti male per il progetto che è stato assegnato allo sviluppatore senior perché probabilmente si rendono conto che questo progetto è troppo "cowboy del selvaggio west" per essere svolto in sicurezza da un nuovo ragazzo.
Come posso assicurarmi che le persone inviino solo richieste non verbali (es. E-mail) di nuove modifiche, in modo che tutto sia chiaro e in anticipo e non ci siano sorprese? Le persone che hanno molta fretta potrebbero aggrottare la fronte quando chiedi loro di fare una richiesta formale.
@Steam Lasciali aggrottare le sopracciglia. L'universo cesserà di esistere perché hai disturbato qualcuno?
Non mi sentirei male per il fatto che lo sviluppatore senior dovesse ripulire questo. Va con il territorio di consentire agli sviluppatori meno senior di lavorare su un codice sufficientemente significativo da poter sviluppare le competenze necessarie per diventare senior. È facile essere irritati dalla necessità di farlo e lasciare che l'irritazione trapeli, ma se il tuo anziano vale la pena, conosce l'affare.
@Steam potrebbero aggrottare le sopracciglia ma capiranno se menzionerai un momento in cui hai avuto seri guai per aver fatto altrimenti. Potresti persino incolpare la politica in modo amichevole. ("Mi dispiace ma il capo mi ucciderà se inserisco il codice senza una richiesta di modifica")
#3
+21
Linda Botes
2012-04-23 14:04:24 UTC
view on stackexchange narkive permalink

Fare un errore come nuovo dipendente è davvero snervante, ma visto che è stato il tuo primo errore è improbabile che verrai licenziato poiché assumere nuovi dipendenti implica sempre e investimenti che saranno riluttanti a perdere.

Suggerirei quanto segue:

  1. Ricordarsi di testare SEMPRE il codice prima della distribuzione. Questa è una regola che non dovresti mai infrangere.

  2. Scopri come funzionano il controllo delle modifiche e il ciclo di sviluppo nella tua azienda, ovvero: le richieste informali sono consentite o devono essere specificate e firmato prima dello sviluppo? Quando e da chi vengono implementate le modifiche? Quando e dove vengono effettuati i test? Se non è in atto un processo controllato, puoi potenzialmente ottenere punti aiutandoli a metterlo in atto ;-) ovvero, il tuo datore di lavoro avrebbe dovuto spiegarti chiaramente questo processo in modo da evitare un errore come questo.

  3. Scopri qual è la riga di comando. Chi ha l'autorità per richiedere e approvare le modifiche? Una volta che hai la risposta, non agire MAI su richieste di modifica da una persona non autorizzata senza aver verificato con l'autorità corretta.

  4. Non è chiaro dal tuo post dove hai implementato le tue modifiche. Li hai distribuiti direttamente su un server di produzione? È essenziale disporre di un server di gestione temporanea o di sviluppo in cui gli sviluppatori possano testare il proprio codice prima della distribuzione in produzione. Per prevenire al meglio questo tipo di errori, idealmente gli sviluppatori non dovrebbero avere accesso diretto ai server di produzione e il codice testato dovrebbe essere distribuito in produzione solo dopo che Q&A lo ha firmato. Ciò dovrebbe avvenire come parte di un processo di controllo delle modifiche controllato.

Assumersi la responsabilità non significa solo ammettere il proprio errore, ma anche prendere parte all'implementazione di processi che fanno funzionare meglio le cose.

Buona fortuna per l'incontro!

Buona risposta, e sembra che questa sia la prima volta in assoluto su qualsiasi sito Stack Exchange, benvenuto!
#4
+13
kevin cline
2012-04-25 19:15:53 UTC
view on stackexchange narkive permalink

Questo processo è seriamente interrotto e non è colpa tua . È assurdo mettere in produzione il codice senza alcuna revisione. Idealmente la modifica dovrebbe essere rivista e dovrebbe essere eseguito un test di regressione completo.

Se il tempo è critico, il minimo assoluto sarebbe che due sviluppatori concordino sulla correzione. In questi casi, la direzione dovrebbe comprendere che esiste una probabilità significativa (> 1%) che la correzione fallisca.

Non sei stato addestrato e non hai autorità sul codice che si trova produzione o il processo di distribuzione. Non assumerti mai la responsabilità quando non hai l'autorità. Spiega cosa ti è stato chiesto di fare e come hai risposto. Una risposta razionale da parte della direzione sarebbe analizzare l'incidente, quindi modificare il processo per evitare che si verifichi in futuro. Qualsiasi altra cosa è irrazionale. Non rimanere in organizzazioni irrazionali.

Oltre a tutto il resto, mettere il codice in produzione il venerdì sera, il che significa più di 60 ore fino a quando non torni e puoi risolverlo, è un male.
#5
+5
DVK
2016-05-25 19:20:33 UTC
view on stackexchange narkive permalink

Sono dovuto tornare indietro e rileggerlo per assicurarmi di averlo interpretato correttamente. Farò anche alcune deduzioni.

Venerdì, quando stavo per lasciare il lavoro, un collega mi ha fermato e mi ha detto di apportare modifiche al codice già funzionante.

Il fatto che questo progetto live sarebbe stato utilizzato durante il fine settimana da un cliente reale in un ambiente di produzione non mi era stato reso noto.

Quindi, in pratica, ti è stato assegnato un incarico senza un scadenza dichiarata esplicitamente e, non sapendo che il tuo check-in sarebbe finito come parte di una versione di produzione, l'hai parzialmente completato venerdì con l'intento di finire dopo il fine settimana? Da bravo sviluppatore, prima di partire per il fine settimana hai controllato i tuoi progressi nel caso in cui l'equipaggio delle pulizie avesse scaricato un secchio di scopa sul tuo computer? Non sembra davvero che tu abbia fatto qualcosa di sbagliato di per sé, tranne che il tuo codice è finito come parte di una versione di produzione. Forse lo sviluppatore senior non pensava che saresti rimasto a lavorare sul codice, e quindi non si è mai preso la briga di parlarti del rilascio (presupposto pericoloso).

Quindi, operando sotto le pretese di cui sopra, qui è come lo approccerei.

Sii concreto e obiettivo

Il tuo post iniziale è già difensivo. "Beh, nessuno me l'ha detto, e il QA normalmente verifica, e .. e .. e .." Non importa a nessuno. Attenersi ai fatti. "Mi è stato chiesto subito prima di partire per lavorare su XYZ. Non sapevo che ci fosse una versione di produzione questo fine settimana e che il codice sarebbe stato incluso. Ho controllato alcune delle mie modifiche prima di partire per il fine settimana, quindi non l'ho fatto non perdere il lavoro, ma non sono stati completati o completamente testati. "

Accetta la responsabilità e chiedi come avresti potuto fare meglio

La responsabilità non è la stessa della colpa. Ammetti di aver controllato il codice con false supposizioni e che ha causato un problema. Quindi, invece di difendere le tue azioni, concentrati su qualcosa di molto più produttivo ... capire come puoi evitare che accada di nuovo. "Se dovessi imbattermi di nuovo in questa situazione, sarebbe meglio se avessi archiviato il mio codice come uno scaffale o non lo avessi archiviato affatto finché non ho ritenuto che fosse pronto per la produzione? Abbiamo un ramo di controllo del codice sorgente separato che dovrei utilizzi per i check-in parziali in modo che non finiscano accidentalmente in una versione di produzione? "

Ascolta le risposte

È sorprendente che questo deve essere detto, ma ascolta cosa ti suggeriscono gli sviluppatori senior e i project manager per prevenire il problema. Le persone generalmente saranno molto più disponibili ad aiutare qualcuno che sanno essere interessante nell'ascolto e nell'apprendimento.

Non è questo il luogo per criticare i processi

Sarebbe totalmente improduttivo entrare nella riunione e dire: "Bene, se la nostra strategia di ramificazione fosse migliore, e avremmo seguito i nostri processi standard, e ..." Questo sembra essere una colpa. Mi sembra che ci sia un problema con il processo (considerando che il codice non testato / non approvato è stato rilasciato in produzione), ma c'è un momento e un luogo per far apparire questi suggerimenti. Il sistema attualmente in uso funziona almeno in minima parte e, sebbene un sistema migliore avrebbe potuto prevenire il problema, cerca di comprendere appieno il sistema attuale prima di puntare il dito contro di esso.

Abbi compassione per te stesso

Sei il nuovo sviluppatore. Hai fatto un errore. Tutti lo abbiamo fatto e continueremo a farlo di tanto in tanto perché siamo umani. Negli anni ho scoperto che, a meno che tu non faccia qualcosa di completamente negligente e incompetente, gli errori di solito non sono la fine di una carriera. Puoi scegliere di spendere le tue energie per picchiarti, difendere le tue azioni o fare le cose per bene e capire come fare meglio in futuro. La maggior parte delle persone rispetterà una persona che dice: "Sì, ho sbagliato. Mi piacerebbe risolvere il problema e sono disposto ad ascoltare".

#6
+4
Jeremy Stein
2012-06-15 09:17:01 UTC
view on stackexchange narkive permalink

Come è entrato in produzione il codice? Gli account sviluppatore non devono avere accesso per distribuire il codice in produzione. Qualsiasi sistema che fa affidamento sugli sviluppatori per usare il buon senso sarà buono come il peggior giudizio. Se c'è una grave conseguenza all'interruzione della produzione (e sembra che ci fosse), dovrebbe esserci un sistema serio per garantire che ogni rilascio sia approvato. Non solo un processo seguito dalle persone, ma privilegi di account che richiedono la persona appropriata per approvare la modifica. Non dovresti essere in grado di distribuire codice non valido alla produzione anche se lo desideri. Se puoi, il problema finale è che il tuo sistema è guasto.

Non ho mai visto burocrazia, politiche e controllo degli accessi sostituire con successo il buon senso, la responsabilità e il buon senso. Ho visto il contrario molte volte però. Sto solo dicendo.
@pap: Buon punto. Forse ho esagerato il mio caso. So solo che mi innervosisco molto quando ho accesso alla produzione e preferisco di gran lunga non poter fare quel particolare errore. Abbiamo avuto tutti quel momento uh-oh in cui ci siamo resi conto che eravamo effettivamente in produzione invece che in sviluppo.
Dove lavoro hanno questa separazione dei ruoli in atto, ma non è applicata in modo molto ponderato o efficace, quindi, la maggior parte delle volte, funziona davvero contro di noi. Anche se potrebbe essere più sicuro, peggiora i tempi di consegna e spesso rende più difficile risolvere un problema. Tuttavia, deve esserci un modo per applicarlo in modo sensato. O forse ciò di cui abbiamo veramente bisogno è una sorta di modo per controllare ogni cambiamento fatto.
#7
+1
Jay
2016-05-25 01:32:53 UTC
view on stackexchange narkive permalink

Sono d'accordo con molto di quello che hanno detto gli altri e non ha senso ripeterlo. Solo alcuni commenti aggiuntivi:

Dovresti certamente ammettere i tuoi errori. Evita di seguire tale ammissione con un "ma" seguito da qualsiasi cosa che suoni come lamentarsi o incolpare gli altri. Detto questo, non accettare la colpa per ciò che non è colpa tua. Evita di nominare nomi a meno che non venga premuto. Come in questo caso, potrei dire: "Mi è stato detto di fare questo cambiamento" senza dire chi me lo ha detto. Certo, se il capo non lo sa, prima o poi lo capirà o lo chiederà, ma eviti di dare l'impressione di cercare di incolpare gli altri se lo fai bene.

Dal tuo post, mi sembra che tu fossi confuso riguardo alle procedure per affidare il lavoro alla biblioteca con la tua azienda, o che l'azienda abbia uno scarso controllo su questo. Normalmente vi impegnate nella libreria solo dopo che il QA ha approvato le modifiche? In caso negativo, come fa la persona responsabile della distribuzione alla produzione a sapere quando le modifiche sono pronte per essere applicate? Se la risposta è "Beh, tipo, dovrebbero solo sapere, sai", allora c'è un problema.

Se ti sono state dette le procedure e non le hai seguite perché eri in fretta di tornare a casa o altro, questo è il tuo problema. Se hai seguito le procedure ma qualcun altro si è schierato prematuramente perché non stava prestando attenzione, non è affatto colpa tua. Se l'azienda non ha un modo chiaro per dire cosa dovrebbe essere implementato e cosa no, questo è il problema dell'azienda.

Alcune persone hanno fatto commenti sulle revisioni tra pari e sull'approvazione del QA. Ovviamente dipende dall'azienda. In una piccola azienda potrebbero non esserci revisioni tra pari o personale addetto al controllo qualità. Nel mio lavoro precedente ho combattuto a lungo per ottenere un vero reparto QA, piuttosto che i test casuali che l'azienda stava facendo.

Ma in ogni caso, il momento in cui ti impegni con la libreria dipende dalle procedure aziendali. In qualunque posto io abbia lavorato, il programmatore prova sul suo desktop, poi quando è soddisfatto si impegna nella libreria. Da lì è impegnato nelle regioni in cui il controllo qualità e / o l'utente può eseguire test. Quindi non puoi necessariamente dire, non impegnarti finché non supera il QA. IMHO ha senso distribuire nella regione QA dalla libreria, quindi deve essere nella libreria prima di poter eseguire il QA. Ma quale sia una buona politica non è la domanda immediata. La domanda è quale sia la politica per la tua azienda e se l'hai seguita.

#8
-1
Andrew T Finnell
2012-04-23 08:53:19 UTC
view on stackexchange narkive permalink

Se avessi saputo che sarebbe stato eseguito domenica dal vivo, avrei testato il codice.

Questo è il tuo primo errore. Perché c'è una pre-condizione per testare il codice? Dovresti sempre testare il tuo codice e non fare mai affidamento sul QA per avere le spalle. Non è compito del QA.

Qualunque cosa tu faccia, non dire nulla di ciò che hai scritto qui durante la riunione. Questa è colpa tua al 100% e l'unica cosa che puoi fare è ammetterlo al 100%. Supponi di averlo rotto, non l'hai testato e che stai attivamente cercando modi per eseguire test unitari e di integrazione in modo che ciò non accada di nuovo.

Ecco un altro modo di vedere le cose. Una delle grandi cose su cui gli ingegneri civili erano soliti rattristare gli ingegneri del software è la responsabilità e la mancanza di licenze. Se un ingegnere civile commette un errore mentre costruisce un ponte e qualcuno viene ucciso mentre guida su di esso, quell'ingegnere è responsabile dell'errore. Riesci a immaginare se fosse andato al telegiornale e avesse detto "Il mio collega non mi ha detto che le macchine ci sarebbero passate sopra durante il fine settimana".

Anche se il software Live potrebbe non essere letteralmente la vita o la morte , per alcune aziende una rottura del sistema Live può essere molto simile a una sensazione simile.

"È colpa tua al 100%" ... e questo è ** sbagliato ** al 100%. Il loro reparto di sviluppo è del tutto troppo avventato per non eseguire la revisione del codice tra pari del codice e dei test unitari prima che qualsiasi cosa vada al QA, per non aver comunicato quando il codice andrà in produzione e per un team QA che non è riuscito a rilevare un problema importante prima di andare in diretta. Certo, tutto è iniziato con lo sviluppatore, ma alla fine ** QUALSIASI ** problema con il software può essere ricondotto allo sviluppatore. Questo è il motivo per cui misuriamo la qualità come le revisioni del codice e i test di accettazione del QA in primo luogo.
-1 per porre il 100% del guasto all'OP. L'OP non è un operatore solitario, lavora come parte di un team e come tale è il team responsabile della consegna, non l'OP. Indica davvero un processo seriamente interrotto.
-1: i sistemi ben progettati dispongono di backup per prevenire il turbamento da inevitabili errori umani. Questo sistema non ne ha.
"Perché c'è una pre-condizione per testare il codice?" Era venerdì sera, fu interrotto mentre usciva dalla porta. L'OP credeva che il codice non fosse utilizzato su un sistema live e la cosa peggiore che sarebbe accaduta se il suo codice non avesse funzionato sarebbe stata un disturbo per l'altro sviluppatore fino a lunedì mattina. OK, forse avrebbe dovuto eseguire un test veloce o qualcosa del genere, ma "100% colpa tua" è estremamente duro.


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