设计模式 – 在软件中永远不会产生未知的途径? [丰田原理]

在丰田生产线上,他们总是知道零件的走向.正因如此,他们可以确定他们可以解决出错的问题.这也适用于软件吗?

所有错误消息都应该告诉我他们走过的路径.有些人,带有堆栈跟踪的错误消息.这是正确的解释吗?它可以用在其他地方吗?

好的,这是播客.我认为这很有意思

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

最佳答案
在可行的情况下,一个好主意.不幸的是,跟踪机器状态的整个历史通常是非常困难的.您无法标记每个数据结构的位置以及该对象的整个状态.您可能只能存储外部事件,并以此方式重现所有内容的来源.

一些例子:

我确实在一个可行的项目上工作,并且它帮助极大.当我们接近发货,并且没有错误来修复时,我们将让我们的游戏以“零玩家模式”进行游戏,计算机将在整个夜晚反复播放所有角色和区域的变化.如果它断言,它将显示开始匹配的随机密钥.当我们上午来上班时,我们会从屏幕上写下按键(通常有一个),然后使用该按键再次启动它.然后我们只是观察它直到断言出现,并追踪它.重要的是我们可以重新创建导致错误的所有原始输入,并且可以按照我们想要的次数重新运行它,即使在重新编译之后(在限制范围内……随机数生成器的提取次数也无法更改)虽然我们有一个单独的RNG用于非游戏内容,例如visual fx).这只能起作用,因为每次匹配都是在热重启后启动的,并且仅使用非常少量的数据作为输入.

我听说Bungie使用类似的方法试图在他们的Halo级别中发现坏几何.他们会设置开发工具包在一个特殊模式下运行一夜之间,其中不可构造的主角将随机移动和跳跃.早上他们会看,看看他是否在某些他无法离开的位置卡在几何体中.也可能涉及手榴弹.

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

转载注明原文:设计模式 – 在软件中永远不会产生未知的途径? [丰田原理] - 代码日志