如何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 路徑太長導致訊號衰減，而造成
讀取錯誤。........天殺的。