※ 引述《banana2014 (香蕉共和國)》之銘言：
: 我大概在兩年前左右做了一個網頁版的聊天室
: 約莫上個月的時候，我無意間發現了一個bug
: 那個bug是對方已經傳了一個新訊息給我，但我這邊卻完全沒收到他傳給我的新訊息
: 但等我重新整理聊天室頁面之後，那個bug就從此徹底銷聲匿跡了
: 而且從兩年前到bug發生當時的那段時間以及bug發生當時至今這段時間，用起來都很正常
: 也就是說那個bug只在上個月那一次發生之後就再也沒被我看到了
0. 你的系統有多重要？你願意花多少代價去修、去整理他？如果是自己做好玩的，用戶
不多、也不打算靠他賺錢，那很多時候就是不修了，接受Bug的存在在資源有限的時候也
是一個選項
1. 重新檢討你的系統怎麼做logging、Monitoring 的，越難纏、越不好重現的Bug，越是
只能靠logging 找出問題，如果寫程式例外處理習慣很差，每次遇到exception 就吃案，
那自然系統一天到晚都會有『難以重現』的Bug
2. 找人來看，找比你懂的人做pair programming 來review系統的設計，必要時先做重構
簡單的說，很多時候系統存在難解的問題，就像是你的房間裡有蟑螂蜘蛛要清掉一樣
如果吃過的便當、喝過的飲料、穿過的衣服等等等的隨便散放在地上，生活習慣極差
想要把蟑螂蜘蛛都給殺光趕跑是不可能的，只有先把房間打掃完，再來驅趕才會有效
而只要生活習慣不改善，遲早會再度變成蟑螂窩的
: 雖然我不是IT業界的專業程式設計師
: 不過我想問一下：
: 當遇到這種程式已寫了兩年以上才難得出現過一次算是有點嚴重的bug被你發現到了
: 通常專業的都怎麼處理?
: 因為這樣的bug或許很難刻意的被製造出來，所以幾乎只能靠運氣碰碰看了
聊天室幾乎肯定會用上critical section，如果你對你採用的programming language
如何做multithreaded programming 觀念有誤，那就容易寫出看起來沒問題，但實際上
問題很多的系統，如果你還用上分散式處理(你的情境應該用不到)，那有問題的機會是
更高的
更多時候我們是會避開需要做multithreaded programming的情境的，因為做得好的情況
少、搞砸的機會多，除非你過去好幾年都是在做這種，不然很難寫好的