2008-09-21 12 views
5

En las líneas de fabricación de Toyota siempre saben qué camino ha recorrido una parte. Para que puedan estar seguros de que pueden solucionarlo, algo va mal. ¿Esto también es aplicable en el software?¿Nunca produce en un camino desconocido, en el software también? [Principio de Toyota]

Todos los mensajes de error deben decirme exactamente qué ruta recorrieron. Algunos lo hacen, los mensajes de error con el seguimiento de la pila. ¿Es esta una interpretación correcta? ¿Podría ser utilizado en otro lugar?

Bien, aquí está el podcast. Creo que es interesante

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

Respuesta

5

Una buena idea cuando sea posible. Desafortunadamente, por lo general es prohibitivamente difícil hacer un seguimiento de la historia completa del estado de la máquina. Simplemente no puede etiquetar cada estructura de datos con el origen, y todo el estado de ese objeto. Es posible que pueda almacenar solo los eventos externos y así reproducir de dónde vino todo.

Algunos ejemplos:

me hicieron trabajar en un proyecto en el que era posible y que ayudaron inmensamente. Cuando nos acercábamos al envío y nos quedábamos sin errores para arreglar, teníamos nuestro juego en el modo "cero jugadores", donde la computadora se reproducía repetidamente durante toda la noche con todas las variaciones de personajes y escenarios. Si afirmaba, mostraría la clave aleatoria que inició el partido. Cuando veníamos a trabajar por la mañana escribíamos la tecla desde nuestra pantalla (usualmente había una) y la comenzamos de nuevo usando esa tecla. Luego, simplemente lo veríamos hasta que apareciera la afirmación, y lo rastrearíamos. Lo importante es que podríamos volver a crear todas las entradas originales que llevaron al error y volver a ejecutarlo tantas veces como quisiéramos, incluso después de recompilar (dentro de los límites ... el número de recuperaciones del generador de números aleatorios no se pudo cambiar , aunque teníamos un RNG separado para cosas que no eran juegos, como visual fx). Esto solo funcionó porque cada partida comenzó después de un reinicio en caliente y solo tomó una cantidad muy pequeña de datos como entrada.

He oído que Bungie usó un método similar para tratar de descubrir la mala geometría en sus niveles de Halo.Pusieron los kits de desarrollo a funcionar durante la noche en un modo especial donde el protagonista indestructible se movería y saltaría al azar. Por la mañana miraban y veían si se quedaba atrapado en la geometría en algún lugar donde no podía salir. Puede haber granadas involucradas, también.

En otro proyecto, realmente registramos toda la interacción del usuario con una marca de tiempo para poder reproducirla. Eso funciona bien si puedes, pero la mayoría de las personas tiene interacciones con un DB cambiante cuyo estado completo podría no almacenarse tan fácilmente.

+0

Buen punto. También utilicé este enfoque "keep info around" para una herramienta de procesamiento, para poder rastrear los errores de entrada que causaban que la salida estuviera corrupta o simplemente fallara tarde (por ejemplo, línea de archivo de entrada donde supuestamente está el error). – steffenj

+0

Mark, estaba leyendo esta respuesta y pensé: "He visto eso hecho antes". Luego vi tu nombre y me di cuenta de que habíamos trabajado juntos. – Nosredna

0

Este es un buen enfoque. Pero ten en cuenta que no debes sobre-hacer el registro. De lo contrario, no podría encontrar la información interesante en todo el ruido, y se reduce el rendimiento general (por ejemplo, la creación de objetos anónimos, dependiendo del idioma).

2

Es menos importante con el software. Si algo falla en el software, generalmente puede reproducir el error y analizarlo en cautividad. Incluso si solo ocurre 1 vez en 1000, a menudo puede encender todo el registro y ejecutarlo 1000 veces (una prueba de remojo simple).

Eso es mucho más costoso y lleva más tiempo en una línea de fabricación, hasta el punto de ser imposible.

Tener tanta información disponible como sea posible la primera vez que sale mal no es algo malo, pero no es tan importante para mí como lo es para Toyota.

0

Producir mensajes de error con un seguimiento de pila completo es generalmente mala práctica de seguridad.
Por otro lado, y más en línea con la intención de Toyota, cada módulo desarrollado debe remontarse a los programadores originales, y deben rendir cuentas por el trabajo de mala calidad, las correcciones de errores, las vulnerabilidades de seguridad, etc. propósitos disciplinarios, pero tanto mantenimiento como educación si es necesario. Y tal vez para bonificaciones, en la situación contraria ... ;-)

0

Me recuerda esta charla en Google Video sobre "depuración al revés en el tiempo". Rara vez (nunca) uso depuradores (y no podía soportar el altavoz jocoso) así que me salté la charla. Quizás es interesante para ti?

Cuestiones relacionadas