如何debug....
上面有蛮多文章看来是蛮认真的RD会做的事情，但是忽略了一些在真实世界会碰到
的状况，而且会因为这样撞的满头包。
首先，要定义什么叫做bug，通常是由其他人经由某种文件格式，回报这个软题的
行为跟预期不同。
例如说某个人哀号：C1设定下去之后萤幕变成黑色的，但是应该要是红色！
第一步骤是，确认这个回报的问提是否是合乎软件规格的，很可能是这个人误会了
软件的规格，或者是拿了错误的规格版本。例如v3.2.7之后天杀的PM改了C1的行为...
如果确定这个回报的资料是正确的，第二部就是复制这个错误。
．．．．．
这又是天杀的难关，大部分好重现或者容易碰到的问题早就在初期解掉了，会交给你
这个菜鸟通常是不好重现。例如说使用者会说他连续操作这个app 30分钟，出现了一
次这个bug....
所以此时你的工作是去复制这个问题，通常在回报文件里面有一大堆不相干的步骤，
或者是步骤少的可怜。总之要靠经验去复制这个问题，而且让这个问题越简单越好。
通常啦，我说通常。反复操作才会出现的问题跟 Memory Leak有关，有机率发生的问题
通常是跟其他元件交互作用而产生的，例如 race condition。
但是也碰过很多环境相关的问题，例如说使用者注册的区码是JP的话会出发问题，用
台哥大的网络因为dns解析错误导致拿不到某个xml而定义烂掉，某个该死的使用者
在名称当中放了一个该死精美的全角空白。。。。。。。。
总之有了简单而容易重现的步骤之后，才能够进入到下一个阶段。通常在研究重制步骤
会让你深刻知道，怎样会发生问题而怎样不会发生问题。借此可以大幅缩小嫌疑犯的
范围。经由反复 a/b testing，加上前面文章提到的 debugging技巧，很快能够抓到凶手
。
嗯，我碰过天杀的kernel panic 是因为 file system curruption，原因是 bootloader
加载到 memory 就是烂的，原因是因为 Flash 的 CLK 路径太长导致讯号衰减，而造成
读取错误。........天杀的。