永远不要在软件中生产未知的途径？[丰田原理][已结束]

这是一个很好的方法。但请注意，您不应该过度记录日志记录。否则，您将无法在所有噪音中找到有趣的信息，并且会降低整体性能（例如，匿名对象创建，具体取决于语言）。

对于软件来说，这不那么重要。如果软件出现问题，您通常可以重现故障并在圈养中对其进行分析。即使它只发生在 1000 次中 1 次，您通常也可以打开所有日志记录并运行 1000 次（一个简单的浸泡测试）。

这在生产线上要昂贵和耗时得多，甚至不可能。

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

使用完整堆栈跟踪生成错误消息通常是不良的安全做法。
另一方面，更符合丰田的意图，每个开发的模块都应该追溯到最初的程序员——他们应该对劣质工作、错误修复、安全漏洞等负责。不是出于纪律目的，而是在必要时进行维护和教育。也许是为了奖金，在相反的情况下...... ;-）

在可行的情况下，一个好主意。不幸的是，跟踪机器状态的整个历史记录通常非常困难。你不能用你从哪里得到它来标记每个数据结构，以及该对象的整个状态。您也许可以只存储外部事件，并以这种方式重现所有内容的来源。

一些例子：

我确实做过一个可行的项目，它帮助很大。当我们快要发货了，并且没有需要修复的错误时，我们会让我们的游戏处于“零玩家模式”，在这种模式下，计算机会整夜重复播放各种角色和区域设置。如果它断言，它将显示开始匹配的随机键。当我们早上上班时，我们会从屏幕上写下这个键（通常有一个），然后用那个键重新开始。然后我们就会观察它，直到断言出现，然后追踪它。重要的是，我们可以重新创建导致错误的所有原始输入，并根据需要多次重新运行它，即使在重新编译后也是如此（在限制范围内......从随机数生成器中获取的数量无法更改，尽管我们有一个单独的 RNG 用于非游戏内容，例如 Visual FX）。这之所以有效，是因为每场比赛都是在热重启后开始的，并且只接受非常少量的数据作为输入。

我听说 Bungie 使用类似的方法试图在他们的 Halo 关卡中发现糟糕的几何形状。他们会将开发套件设置为在特殊模式下通宵运行，在这种模式下，坚不可摧的主角会随机移动和跳跃。早上，他们会看看他是否被困在几何图形中，在他无法离开的地方。可能还涉及手榴弹。

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