在软件中,永远不会产生一条未知的路径?[丰田原则][关闭]

一个可行的好主意。不幸的是,通常很难追踪机器状态的整个历史。您不能标记每个数据结构的来源以及 那个 对象。您可能只能够存储外部事件,并以这种方式复制所有事物的来源。

一些例子:

我在一个可行的项目上工作,这对我有很大帮助。当我们快要出货了,并且要修复的bug用完时,我们的游戏将在“零玩家模式”下进行,在这种模式下,计算机将整夜重复地使用各种不同的角色和区域进行游戏。如果它断言,它将显示开始匹配的随机键。当我们早上上班的时候,我们会把屏幕上的键写下来(通常有一个),然后用那个键重新启动。然后我们只需观察它,直到断言出现,并跟踪它。重要的是,我们可以重新创建导致错误的所有原始输入,并根据需要多次重新运行它,即使在重新编译之后(在限制范围内)。从随机数生成器中提取的数量无法更改,尽管我们有一个单独的RNG用于非游戏内容,如VisualFX)。这只会起作用,因为每次匹配都是在热重启之后开始的,并且只接受非常少量的数据作为输入。

我听说邦吉用了类似的方法试图发现他们光环水平的糟糕几何结构。他们会将开发工具包设置为一种特殊的模式,在这种模式下,坚不可摧的主角可以随意移动和跳跃。早上,他们会看一看,看他是不是在某个他不能出去的地方,被几何图形卡住了。可能也有手榴弹。

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

它对软件来说不那么重要。如果软件出了问题,您通常可以重现故障并进行人工分析。即使每1000次只发生一次,您也可以经常打开所有日志并运行1000次(一个简单的浸泡测试)。

在一条生产线上,这要花费更多的成本和时间,甚至是不可能的。

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

这是一个很好的方法。但要注意不要过度砍伐。否则,在所有噪声中都找不到有趣的信息,这会降低整体性能(例如,匿名对象创建,取决于语言)。

生成具有完整堆栈跟踪的错误消息是 通常 糟糕的安全措施。
另一方面,更符合丰田的意图,每一个开发的模块都应该追溯到最初的程序员,他们应该对劣质的工作、错误修复、安全漏洞等负责,而不是出于纪律目的,而是维护和教育(如有必要)。也许对于奖金,在相反的情况下…;-)