Ne jamais produire sur une voie inconnue, dans le logiciel aussi? [Principe Toyota] [fermé]

Question

Dans les chaînes de fabrication de Toyota, ils savent toujours quel chemin une pièce a emprunté. Juste pour qu'ils puissent être sûrs de pouvoir résoudre ce problème. Est-ce que cela s'applique aussi au logiciel?

Tous les messages d'erreur doivent me dire exactement quel chemin ils ont emprunté. Certains le font, les messages d'erreur avec trace de pile. Est-ce une interprétation correcte? Pourrait-il être utilisé ailleurs?

Ok, voici le podcast. Je pense que c'est intéressant

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

Answer 1

Une bonne idée lorsque cela est réalisable. Malheureusement, il est généralement extrêmement difficile de garder une trace de l’ensemble de l’historique de l’état de la machine. Vous ne pouvez tout simplement pas baliser chaque structure de données avec son origine, et l'état complet de cet objet . Vous pourrez peut-être ne stocker que les événements externes et ainsi reproduire d'où tout vient.

Quelques exemples:

J'ai travaillé sur un projet qui était réalisable et qui m'a énormément aidé. Lorsque nous approchions des expéditions et que nous étions à court de bugs à résoudre, notre jeu se jouait en mode "zéro joueur", où l'ordinateur se jouait de manière répétée toute la nuit, avec toutes les variations de personnages et de lieux. Si cela se vérifiait, cela afficherait la clé aléatoire qui a commencé le match. Lorsque nous arrivions au travail le matin, nous écrivions la clé sur notre écran (il y en avait généralement une) et recommençions à l’aide de cette clé. Ensuite, nous le regarderions jusqu'à ce que l'affirmation vienne et le traquer. L'important est que nous puissions recréer toutes les entrées d'origine ayant conduit à l'erreur et les réexécuter autant de fois que nous le souhaitions, même après une recompilation (dans les limites… le nombre d'extraits du générateur de nombres aléatoires ne pouvait pas être modifié. , bien que nous ayons un RNG séparé pour des choses non liées au jeu comme les effets visuels). Cela ne fonctionnait que parce que chaque match commençait après un redémarrage à chaud et ne prenait qu'une très petite quantité de données en entrée.

J'ai entendu dire que Bungie avait utilisé une méthode similaire pour essayer de détecter une mauvaise géométrie dans leurs niveaux de Halo. Ils placeraient les kits de développement en cours de nuit dans un mode spécial où le protagoniste indestructible se déplacerait et sauterait au hasard. Dans la matinée, ils verraient s'il voyait s'il était coincé dans la géométrie à un endroit où il ne pourrait pas sortir. Des grenades ont peut-être aussi été impliquées.

Sur un autre projet, nous avons enregistré toutes les interactions de l'utilisateur avec un horodatage afin de pouvoir le rejouer. Cela fonctionne très bien si vous le pouvez, mais la plupart des gens ont des interactions avec une base de données changeante dont l'état complet pourrait ne pas être stocké aussi facilement.

Answer 2

C'est moins vital avec les logiciels. En cas de problème dans le logiciel, vous pouvez généralement reproduire le problème et l’analyser en captivité. Même si cela ne se produit qu'une fois sur 1 000, vous pouvez souvent activer toute la journalisation et l'exécuter 1 000 fois (un simple test d'imprégnation).

C'est beaucoup plus coûteux et prend beaucoup de temps sur une chaîne de fabrication, au point d'être impossible.

Disposer du plus grand nombre d’informations possible la première fois que cela ne va pas, ce n’est pas une mauvaise chose, mais ce n’est pas aussi important pour moi que pour Toyota.

Answer 3

C’est une bonne approche. Mais sachez que vous ne devriez pas trop vous enregistrer. Sinon, vous ne retrouveriez pas les informations intéressantes dans tout le bruit, ce qui réduirait les performances globales (par exemple, la création d’objets anonymes, en fonction de la langue).

Answer 4

La production de messages d'erreur avec une trace de pile complète est généralement une mauvaise pratique de sécurité.
D'un autre côté, et conformément aux intentions de Toyota, chaque module développé devrait remonter au (x) programmeur (s) d'origine - et ils devraient être tenus responsables du travail médiocre, des corrections de bugs, des vulnérabilités de sécurité, etc. Pas à des fins disciplinaires , mais à la fois entretien et éducation si nécessaire. Et peut-être pour les bonus, dans la situation contraire ...; -)