在丰田生产线中，他们总是知道零件走过的路。这样他们就可以确定可以解决某些错误。这也适用于软件吗？

所有错误消息都应准确告诉我它们经过的路径。有些人这样做，错误消息带有堆栈跟踪。这是正确的解释吗？可以在其他地方使用吗？

好的，这是播客。我觉得很有趣

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

解决方案

这是一个好方法。但是请注意，我们不应过度执行日志记录。否则，我们将无法在所有杂音中找到有趣的信息，这会降低整体性能(例如，根据语言创建匿名对象)。

对于软件而言，它的重要性不那么重要。如果软件出了点问题，通常可以重现故障并在被囚禁的情况下对其进行分析。即使它仅在1000中发生1次，我们也可以经常打开所有日志记录并运行1000次(一个简单的浸泡测试)。

在生产线上这要昂贵得多，而且很费时间，以至于不可能。

第一次出错时，尽可能多地获取信息并不是一件坏事，但这对我来说并不像对丰田那么重要。

产生具有完整堆栈跟踪的错误消息通常是不安全的做法。
另一方面，为了更符合丰田的意图，每个开发的模块都应追溯到最初的程序员，并对虚假的工作，错误修复，安全漏洞等负责。但同时进行维护和必要的教育。在相反的情况下，也许是为了获得奖金……;-)。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

一个可行的好主意。不幸的是，跟踪机器状态的整个历史通常非常困难。我们只是无法标记每个数据结构的来源以及该对象的整个状态。我们也许可以只存储外部事件，并以此方式再现一切的来源。

一些例子：

我在一个可行的项目上做过工作，并且对它有极大的帮助。当我们快要出货时，并且要解决所有的错误时，我们将使游戏在"零玩家模式"下进行，在该模式下，计算机将整夜重复播放自己的角色和语言区域的所有变体。如果断言，它将显示开始匹配的随机密钥。早上上班时，我们将从屏幕上写下密钥(通常是一个)，然后使用该密钥重新启动。然后，我们将一直观察直到断言出现为止，然后对其进行跟踪。重要的是，即使重新编译后，我们也可以重新创建所有导致错误的原始输入，并根据需要多次运行它(在限制范围内……从随机数生成器获取的次数不能更改) ，尽管我们为非游戏内容(例如visual fx)提供了单独的RNG)。这样做之所以有效，是因为每次比赛都在热重启后开始，并且只接受了非常少量的数据作为输入。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

我听说Bungie使用类似的方法尝试在其Halo等级中发现不良的几何形状。他们会将开发套件设置为在特殊模式下通宵运行，其中坚不可摧的主角会随机移动和跳跃。早上，他们会看他是否在无法离开的某个位置陷入了几何形状。也可能涉及手榴弹。

在另一个项目中，我们实际上记录了所有带有时间戳的用户交互，因此我们可以重播它。如果可以的话，这很好用，但是大多数人都与不断变化的数据库交互，而数据库的整个状态可能不那么容易存储。

让我想起了Google视频上有关"及时调试"的话题。我很少(从来没有)使用调试器(也无法忍受说了话的人)，所以我跳过了这个话题。也许这对我们很有趣？