2008-09-21 8 views
5

In Toyota Fertigungslinien wissen sie immer, welchen Weg ein Teil zurückgelegt haben. Nur so können sie sicher sein, dass sie etwas reparieren können, das schief läuft. Gilt das auch für Software?Produzieren Sie nie zu einem unbekannten Weg, in der Software auch? [Toyota Prinzip]

Alle Fehlermeldungen sollten mir genau sagen, welchen Weg sie zurückgelegt haben. Einige tun die Fehlermeldungen mit Stack-Trace. Ist das eine korrekte Interpretation? Könnte es woanders benutzt werden?

Ok, hier ist der Podcast. Ich denke, es ist interessant

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

Antwort

5

Eine gute Idee wo praktikabel. Leider ist es in der Regel schwierig, den Überblick über die gesamte Geschichte des Maschinenzustands zu behalten. Sie können einfach nicht jede Datenstruktur mit dem, wo Sie es bekommen haben, und den gesamten Zustand , dass Objekt. Vielleicht können Sie nur die externen Ereignisse speichern und auf diese Weise reproduzieren, woher alles kommt.

Einige Beispiele:

Ich habe die Arbeit an einem Projekt, bei dem es möglich war und es half immens. Als wir uns dem Versand näherten und keine Bugs mehr lösten, mussten wir unser Spiel im "Zero-Players-Modus" spielen, in dem der Computer sich die ganze Nacht über mit allen Variationen von Charakteren und Schauplätzen wiederholt. Wenn es aktiviert wurde, würde es den zufälligen Schlüssel anzeigen, der das Match gestartet hat. Wenn wir morgens zur Arbeit kamen, schrieben wir den Schlüssel von unserem Bildschirm herunter (normalerweise gab es einen) und starte ihn erneut mit diesem Schlüssel. Dann guckten wir es uns einfach an, bis die Behauptung aufkam, und spürten es auf. Das Wichtigste ist, dass wir alle ursprünglichen Eingaben, die zu dem Fehler geführt haben, neu erstellen und sie so oft wiederholen konnten, wie wir wollten, selbst nach der Neukompilierung (innerhalb der Grenzen ... konnte die Anzahl der Aufrufe aus dem Zufallszahlengenerator nicht geändert werden) , obwohl wir einen separaten RNG für Nicht-Spiel-Sachen wie Visual FX hatten). Dies funktionierte nur, weil jede Übereinstimmung nach einem Warmstart gestartet wurde und nur sehr wenige Daten als Eingabe verwendet wurden.

Ich habe gehört, dass Bungie eine ähnliche Methode verwendet, um zu versuchen, schlechte Geometrie in ihren Halo-Ebenen zu entdecken.Sie würden die Dev-Kits über Nacht in einem speziellen Modus laufen lassen, in dem der unzerstörbare Protagonist sich willkürlich bewegen und springen würde. Am Morgen würden sie nachsehen und sehen, ob er in der Geometrie an einer Stelle feststeckte, wo er nicht heraus konnte. Möglicherweise waren auch Granaten beteiligt.

Bei einem anderen Projekt haben wir tatsächlich alle Benutzerinteraktionen mit einem Zeitstempel protokolliert, so dass wir sie erneut abspielen konnten. Das funktioniert gut, wenn Sie können, aber die meisten Leute haben Interaktionen mit einer sich ändernden DB, deren gesamter Zustand möglicherweise nicht so leicht gespeichert wird.

+0

Guter Punkt. Ich habe diese "keep info around" -Ansicht auch für ein Verarbeitungstool verwendet, so dass Fehler von Eingaben, die die Ausgabe beschädigten oder nur zu spät scheiterten, verfolgt werden konnten (z. B. Zeile der Eingabedatei, in der der Fehler angeblich enthalten ist). – steffenj

+0

Mark, ich habe diese Antwort gelesen und dachte: "Das habe ich schon mal gesehen." Als ich deinen Namen sah, wurde mir klar, dass wir zusammen gearbeitet hatten. – Nosredna

0

Dies ist ein guter Ansatz. Aber seien Sie sich bewusst, dass Sie die Protokollierung nicht überfordern sollten. Sonst könnten Sie die interessanten Informationen nicht im gesamten Rauschen finden, und es reduziert die Gesamtleistung (z. B. anonyme Objekterstellung, abhängig von der Sprache).

2

Es ist weniger wichtig mit Software. Wenn in der Software ein Fehler auftritt, können Sie den Fehler normalerweise reproduzieren und in Gefangenschaft analysieren. Selbst wenn es nur einmal in 1000 passiert, können Sie oft die gesamte Protokollierung einschalten und es 1000-mal ausführen (ein einfacher Einweich-Test).

Das ist viel teurer und zeitaufwendiger in einer Fertigungslinie, bis es unmöglich ist.

So viele Informationen wie möglich zur Verfügung zu haben, ist das erste Mal, wenn es schief geht, keine schlechte Sache, aber es ist nicht so wichtig für mich wie für Toyota.

0

Die Erstellung von Fehlermeldungen mit einem vollständigen Stack-Trace ist in der Regel schlechte Sicherheitsvorkehrung.
Auf der anderen Seite, und mehr in Übereinstimmung mit Toyotas Absicht, sollte jedes entwickelte Modul zu den ursprünglichen Programmierern zurückverfolgt werden - und sie sollten für schäbige Arbeit, Bugfixes, Sicherheitslücken usw. zur Rechenschaft gezogen werden disziplinarische Zwecke, aber sowohl Wartung und Ausbildung, wenn nötig. Und vielleicht für Boni, im gegenteiligen Fall ... ;-)

0

Erinnert mich an dieses Gespräch vorbei an Google Video über "Debugging rückwärts in der Zeit". Ich verwende selten (nie) Debugger (und konnte den scherzhaften Sprecher nicht aushalten), also übersprang ich das Gespräch. Vielleicht ist es für dich interessant?