我这两天总有一种想法，这种想法基本可以总结为这样的结论：我们所作的一切事情，就是为了发现问题，或者更清晰的说，为了
定义问题。因为问题一旦被定义，就意味着其解决方法已经非常清晰。我们不能解决问题的根本原因在于我们对问题认识的还不够
深入，我们还不知道问题是什么。
今天本来在看《你的灯亮着吗》，对里面提出的几个问题颇有感触，想到了一个问题：软件为什么会有bug？
wiki上对software bug给了一些解释
但是这不能满足我的需求，那么，为什么软件会有bug呢？
这个问题应该是谁的问题？
1. 程序员
2. 开发经理
3. 需求定义制定者
4. 公司领导
5. 客户
6. 没有为什么，就是有bug
这是程序员的责任吗？人的认识总是有限的，我们不能等待对这个深入研究之后再动手，而是边做边发现问题，然后解决问题。也
就是说，在做之前，我们是不知道问题的，所以，出现bug其实是发现问题的一个基本方法。而在做之前，程序员是不知道这些问题
的。
是开发经理的责任吗？开发经理虽然有经验，有技术，但是并不是所有的业务情况都了如指掌，世界在变化，他之前的经验可能无
法用在这个项目上面，或者某些变化的地方没有考虑到，直到问题显现。也就是，他也没有办法去定义那些隐含的问题。
后面的类似，没有人知道问题会以什么样的形式出现，也没有人能明确定义项目可能出现的种种问题，所以，犯错是必然的，犯错
是发现问题的一个十分重要的方法。至此，我们不能做过多的要求了。
在《你的灯亮着吗》这本书里面，颇有一些非常有警示意义的言辞
1. 问题永远不会被明确定义，也不会被解决完毕，一个问题的解决必然带来另外的问题，我们要清楚问题是什么，而不是解决所有
问题，这似乎是bug mannagement的精髓。
2. 弄清楚问题的根源。
3. 这是谁的问题，不要试图解决不是你的问题。
4. 要让问题解决这感受问题所在，比如你要让老板知道你对薪水不满。
在看software bug的过程中，正好看到了关于arithmetic sub/overflow的问题，跟前段时间的实践结合起来，正好记录一下。
，这个里面提供了加减乘除的时候，检测sub/overflow的方法。
其中的这三项原则还是有些作用的
1. Cast the numbers to a bigger integer type, then do the addition there, and check if the result is in the
right range.
2. Do the addition normally, then check the result (e.g. if (a+23<23) overflow).
3. Check before adding whether the number you add can fit (requires knowledge of the maximum value for that data
type)
关键不是如何做，而是决定是否要做，这很重要。方法总是很多的，关键是问题需要解决吗？问题有没有被定义错误？我们需要处
理这种溢出吗？
abs也会有风险，比如对于abs(0xffffffff)=0xffffffff，因为abs做的是取反加一，由于溢出，则正好回归本身。就出错了。
还有就是小数相乘的时候，可以是用log来避免精度损失，比如
a*b = exp(log(a)+log(b))，但是log和pow都是耗时的操作，所以我们可以使用
frexp进行拆解，将小数拆成significant和exponent两个部分，然后使用ldexp来合并，速度大概是log和exp的三倍左右
，这里也有讨论，可以使用更多的
方法，比如GMP库，比如专用的CPU等
阅读(533) | 评论(0) | 转发(0) |
