在丰田生产线上，他们总是知道零件走过的路径。正因如此，他们可以确定他们可以解决出错的问题。这也适用于软件吗？
所有错误消息都应该告诉我他们走过的路径。有些人，带有堆栈跟踪的错误消息。这是正确的解释吗？可以在其他地方使用吗？
好的，这是播客。我觉得很有意思
答案 0 :(得分：5)
在可行的情况下一个好主意。不幸的是，跟踪机器状态的整个历史通常是非常困难的。您无法标记每个数据结构与您从何处获取数据结构，以及那个对象的整个状态。您可能只能存储外部事件，并以这种方式重现所有内容的来源。
一些例子：
我确实在一个可行的项目上工作，并且它帮助极大。当我们接近发货，并且没有错误来修复时，我们将让我们的游戏以“零玩家模式”进行游戏，计算机将在整个夜晚反复播放所有角色和区域的变化。如果它断言，它将显示开始匹配的随机密钥。当我们上午来上班时，我们会从屏幕上写下按键（通常有一个），然后使用该按键再次启动它。然后我们只是观察它直到断言出现，并追踪它。重要的是我们可以重新创建导致错误的所有原始输入，并且可以按照我们想要的次数重新运行它，即使在重新编译之后（在限制范围内......随机数生成器的提取次数也无法更改）虽然我们有一个单独的RNG用于非游戏内容，如visual fx）。这只能起作用，因为每次匹配都是在热重启后启动的，并且仅使用非常少量的数据作为输入。
我听说Bungie使用类似的方法试图在他们的Halo级别中发现坏几何。他们会设置开发工具包在一个特殊模式下运行一夜之间，其中不可构造的主角将随机移动和跳跃。在早上他们会看，看看他是否在某些他无法离开的位置卡在几何体中。也可能涉及手榴弹。
在另一个项目中，我们实际使用时间戳记录了所有用户交互，因此我们可以重放它。如果可以的话，这很有效，但大多数人都与不断变化的数据库进行交互，而整个状态可能不会那么容易存储。
答案 1 :(得分：2)
软件不太重要。如果软件出现问题，您通常可以重现故障并在人工饲养中进行分析。即使它只在1000中发生一次，您也可以经常打开所有日志记录并运行1000次（简单的浸泡测试）。
在生产线上这是非常昂贵和耗时的，甚至是不可能的。
第一次出错时尽可能多地提供信息并不是坏事，但对我来说并不像丰田那样重要。
答案 2 :(得分：0)
这是一个很好的方法。但请注意，您不应该过度记录。否则你无法在所有噪声中找到有趣的信息，它会降低整体性能（例如，匿名对象的创建，取决于语言）。
答案 3 :(得分：0)
使用完整堆栈跟踪生成错误消息通常是 错误的安全措施 另一方面，更符合丰田的意图，每个开发的模块都应追溯到原始程序员 - 他们应该对劣质工作，错误修复，安全漏洞等负责。不用于纪律目的，但必要时维护和教育。也许是奖金，相反的情况......; - ）