※ 引述《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的情境的，因為做得好的情況 少、搞砸的機會多，除非你過去好幾年都是在做這種，不然很難寫好的 -- 在灣區打工的中年外籍碼農，有誰創業瞧得起在下的，歡迎聊聊 -- ※ 發信站: 批踢踢實業坊(ptt.org.tw), 來自: 123.194.158.240 (臺灣) ※ 文章網址: https://ptt.org.tw/Soft_Job/M.1662512881.A.2EA