方法论：当我们谈论bug的时候我们在谈论什么

初见问题

近日做毕业设计，需要写一个卡尔曼滤波的程序。对于这个卡尔曼滤波的程序，我需要实现的一个功能就是对比在不同误差的条件下，误差对卡尔曼滤波性能的影响。所以我采取的手段是一次次改变噪声的特性（比如方差之类的），绘制一条噪声相关的曲线，这一过程，我是用一个for循环实现的。

苦苦探究

程序出现问题很正常，对于一般情况，如果是语法错误很好解决，但是出现逻辑问题就很麻烦。这回我的问题在于逻辑错误。首先，当然怀疑公式是否错误。但是经过检查，公式是没有问题的。卡尔曼滤波本身公式比较简单，虽然网上矩阵表示的公式用matlab实现的程序较少，但是卡尔曼滤波matlab实现等书籍中有着相关的例程，初学者已经够用了。
然后对于卡尔曼，自然会怀疑是否是因为参数选择的影响，于是查阅资料，发现噪声矩阵对于卡尔曼滤波性能影响的确很大，于是乎又学习了一波噪声矩阵的影响，算是倒逼自己学习了一波，但事实证明，最后问题不是出在这里。可能我还是没弄太清楚，但是可以有以下结论如果程序的结果出现很明显的问题，那么一定不是参数选择不对，而是有其他的隐患。于是希望寻找其他的问题。
其实调试bug的基本原则很简单，二分法。排除掉有效的程序，缩小自己需要解决问题的范围。不过，除此之外，应该寻找一些技术之外的措施，比如与人交流。我的室友也做卡尔曼滤波，当然用的具体模型是不一样的。于是我向他要来了他的卡尔曼滤波程序，对比两个程序，公式层面是一样的，所以基本可以排除是公式导致的bug。并且，他并不能讲出噪声矩阵选取的原则，所以也可以排除参数选择的问题。如果能早点和人讨论，可能可以进一步缩小范围。
接下来，就是对程序的肉搏。总结这回的经验，觉得找bug一方面遵循二分法，一方面遵循俄罗斯套娃原则。即先检查外面的壳，再检查里面的核。即，找bug的核心要义是和找人找手机找对象相同的，即缩小范围，精准打击。比如，在此回的调试过程中，关注几个重要变量的意义，从而找出离奇的变量出现在何处，从而精确定位问题代码。

真像大白

前面不是讲我写了一个循环吗。问题就出在循环里面。这回算是贴身肉搏，一步步debug找到的。如果再给我一个机会，一定是俄罗斯套娃原则。即先以一个循环为单位，看各个循环之间的关系，再进入循环里面看具体的细节。
每次循环都一样吗？未必。可能你希望的是每次循环都一样，但是问题就在于天不遂人愿。这回我出现的问题就在于，没有及时地清楚上一轮循环的变量，从而导致了上一轮的变量对下一轮造成影响。出现这个问题，其实也是因为最小二乘法对我的误导。之前做过一个最小二乘法，但是最小二乘法没有增益矩阵来调整状态和观测间的关系，所以上一轮的变量影响不了下一轮，但是卡尔曼就不是这样了。
然后写的是matlab，对变量分配以及删除方面实在不够敏感。只能说一句，C++牛逼了，不过，在用矩阵的时候，还是真香真香~