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