Nunca producir a un desconocido de la vía, en el software?[Toyota principio] [cerrado]

Question

En Toyota líneas de fabricación que siempre saben qué camino una parte han viajado.Sólo por lo que puede estar seguro de que se puede arreglar de que algo va mal.Es esto aplicable en software?

Todos los mensajes de error debería decirme exactamente lo que el camino que recorrió.Algunos lo hacen, los mensajes de error con el seguimiento de la pila.Es esta una interpretación correcta?Podría ser utilizado en otras partes?

Ok, aquí está el podcast.Yo creo que es muy interesante

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

Answer 1

Una buena idea siempre que sea posible.Por desgracia, generalmente es prohibitivamente difícil seguir la pista de toda la historia del estado de la máquina.Usted simplemente no puede etiqueta de cada estructura de datos con la que se consiguió, y todo el estado de que objeto.Usted puede ser capaz de almacenar sólo los eventos externos y en que forma, reproducir donde todo proviene.

Algunos ejemplos:

Me hizo trabajar en un proyecto que fue posible y ayudó inmensamente.Cuando estábamos cerca de gastos de envío, y la ejecución de los errores a corregir, tendríamos a nuestro juego en "cero jugadores en modo", donde el equipo repetidamente el mismo juego toda la noche con todas las variaciones de personajes y localizaciones.Si se afirma, podría mostrar la clave aleatoria que comenzó el partido.Cuando nos vinieron a trabajar en la mañana, nos gustaría escribir la clave de nuestra pantalla (normalmente era uno) y se comienza de nuevo con dicha clave.Luego nos volveríamos a ver hasta la aserción subió, y la pista de abajo.Lo importante es que podríamos recrear todos los originales de las entradas que ha causado el error y vuelva a ejecutar tantas veces como queríamos, incluso después de recompilaciones (dentro de los límites...el número de búsquedas desde el generador de números aleatorios no podía ser cambiado, a pesar de que había separado RNG para no juego cosas como visual fx).Esto sólo funcionó porque cada partido comenzó después de una cálida reinicio y se llevó sólo un cantidad muy pequeña de datos como entrada.

He oído que Bungie se utiliza un método similar para tratar de descubrir la geometría mal en su Halo niveles.Que establece los dev kits de ejecución de la noche a la mañana en un modo especial donde los indestructibles protagonista iba a mover y saltar al azar.En la mañana se había vistazo y ver si se queda atascado en la geometría en algún lugar donde no podía salir.Puede haber sido granadas involucrados, también.

En otro proyecto que registra toda la interacción del usuario con una marca de tiempo así que podría volver a repetirlo.Que funciona muy bien si se puede, pero la mayoría de las personas tienen interacciones con un cambio de DB cuyo estado puede no ser almacenado tan fácilmente.

Answer 2

Es menos vital con el software.Si algo va mal en el software, usted generalmente puede reproducir el error y analizar en cautiverio.Incluso si sólo ocurre 1 vez en 1000, a menudo se puede cambiar en todo el registro y ejecutar 1000 veces (una simple prueba de inmersión).

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

Tener la mayor cantidad de información disponible como sea posible la primera vez que va mal es no es malo, pero no es tan importante para mí como lo es para Toyota.

Answer 3

Este es un buen enfoque.Pero tenga en cuenta que usted no debe sobre-hacer el registro.De lo contrario, usted podía encontrar las informaciones interesantes en todo el ruido y reduce el rendimiento general (por ejemplo,anónimo creación de un objeto, dependiendo del idioma).

Answer 4

La producción de los mensajes de error con un completo seguimiento de la pila es generalmente la mala práctica de seguridad.
Por otro lado, y más en línea con Toyota intención, cada módulo desarrollado debe ser trazada para el programador original(s) - y deben ser responsables por la mala calidad de los trabajos, correcciones de errores, vulnerabilidades de seguridad, etc.No para propósitos disciplinarios, pero tanto el mantenimiento y la educación, si es necesario.Y tal vez para los bonos, en la situación opuesta...;-)