※ 引述《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的情境的，因为做得好的情况
少、搞砸的机会多，除非你过去好几年都是在做这种，不然很难写好的