Mai produrre su un percorso sconosciuto, anche nel software? [Principio Toyota] [chiuso]

Question

Nelle linee di produzione Toyota sanno sempre quale percorso ha percorso una parte. Solo così possono essere sicuri di poter risolvere qualcosa che non va. Questo è applicabile anche nel software?

Tutti i messaggi di errore dovrebbero dirmi esattamente quale percorso hanno percorso. Alcuni lo fanno, i messaggi di errore con stack stack. È un'interpretazione corretta? Potrebbe essere usato da qualche altra parte?

Ok, ecco il podcast. Penso che sia interessante

http://itc.conversationsnetwork.org/shows/detail3798.html

Answer 1

Una buona idea dove possibile. Sfortunatamente, di solito è proibizionalmente difficile tenere traccia dell'intera storia dello stato della macchina. Non puoi semplicemente etichettare ogni struttura di dati con la provenienza e l'intero stato di quell'oggetto . Potresti essere in grado di memorizzare solo gli eventi esterni e in questo modo riprodurre da dove proviene tutto.

Alcuni esempi:

Ho lavorato su un progetto in cui era praticabile e mi ha aiutato immensamente. Quando ci stavamo avvicinando alla spedizione ed eravamo a corto di bug da correggere, avremmo avuto il nostro gioco in modalità "zero giocatori", in cui il computer si sarebbe ripetutamente giocato per tutta la notte con tutte le varianti di personaggi e locali. Se affermasse, visualizzerebbe la chiave casuale che ha iniziato la partita. Quando arrivavamo al lavoro la mattina scrivevamo la chiave dal nostro schermo (di solito ce n'era una) e la ricominciavamo usando quella chiave. Quindi lo guarderemmo fino a quando l'asserzione non arrivasse e l'avremmo rintracciata. L'importante è che potremmo ricreare tutti gli input originali che hanno portato all'errore e rieseguirlo tutte le volte che volevamo, anche dopo la ricompilazione (entro limiti ... il numero di recuperi dal generatore di numeri casuali non poteva essere modificato , sebbene avessimo un RNG separato per cose non di gioco come visual fx). Questo ha funzionato solo perché ogni partita è iniziata dopo un riavvio a caldo e ha richiesto solo una quantità molto piccola di dati come input.

Ho sentito che Bungie ha usato un metodo simile per cercare di scoprire geometrie errate nei loro livelli di Halo. Avrebbero impostato i kit di sviluppo in esecuzione durante la notte in una modalità speciale in cui il protagonista indistruttibile si muoveva e salta in modo casuale. Al mattino guardavano e vedevano se si fosse bloccato nella geometria in un punto in cui non poteva uscire. Potrebbero essere state coinvolte anche granate.

Su un altro progetto abbiamo effettivamente registrato tutte le interazioni dell'utente con un timestamp in modo da poterlo riprodurre. Funziona alla grande se puoi, ma la maggior parte delle persone ha interazioni con un DB che cambia il cui intero stato potrebbe non essere memorizzato così facilmente.

Answer 2

È meno vitale con il software. Se qualcosa non funziona nel software, di solito è possibile riprodurre l'errore e analizzarlo in cattività. Anche se accade solo 1 volta su 1000, puoi spesso attivare tutta la registrazione ed eseguirlo 1000 volte (un semplice test di immersione).

È molto più costoso e richiede molto tempo su una linea di produzione, al punto da essere impossibile.

Avere quante più informazioni disponibili la prima volta che va storto non è male, ma per me non è così importante come lo è per Toyota.

Answer 3

Questo è un buon approccio. Tuttavia, tieni presente che non dovresti eseguire una registrazione eccessiva. Altrimenti non è possibile trovare le informazioni interessanti in tutto il rumore e ciò riduce le prestazioni complessive (ad es. Creazione di oggetti anonimi, a seconda della lingua).

Answer 4

La produzione di messaggi di errore con una traccia dello stack completo è in genere una cattiva pratica di sicurezza.
D'altra parte, e più in linea con l'intento di Toyota, ogni modulo sviluppato dovrebbe essere ricondotto ai programmatori originali e dovrebbero essere ritenuti responsabili per lavori scadenti, correzioni di bug, vulnerabilità di sicurezza, ecc. Non a fini disciplinari , ma sia la manutenzione che l'educazione, se necessario. E forse per i bonus, nella situazione contraria ... ;-)