主要是很多吃瓜群眾不明真相。
事實上，bug 有很多種。
Bug 分很多類，一類是對用戶來說不能正常使用，能被用戶感知到的錯誤。一類是用戶能正常使用，但是有各種異常的錯誤。一類是使用沒有任何問題，但是不符合產品預期的問題。
1 顯然，第三種就很難杜絕。
畢竟：因為信息不對稱，預期是產品經理和程序員的信息不對稱，因為文字是有二義性的，況且人和人對相同文本的理解本來就可能出現偏差，這就導致瞭需求理解的不一致，最終導致瞭線上產品不符合預期。對於內部人員來說，這個也算 BUG。以及，有的產品在推廣過程中，定位等大方向都發生瞭便宜，和當初寫程序的時候已經大不同，則很可能要改。
2 人不是機器
人不像機器，不可能不犯錯；同樣的，不可能存在沒有 bug 的程序，像大傢使用的 windows，窮盡無數優秀的工程師，給予用戶優秀的桌面體驗的同時，也有你可能完全看不到的數千個 bug。即便是機器，也有失控的時候。
3 需求多變
有時候領導的想法變來變去的，就會導致產品也變來變去，程序員也跟著遭殃。很多情況下一個需求的變化，程序會帶來很多問題，有可能連底層結構都需要跟著一起變動。頻繁的需求變動，加上開發周期和成本的約束，帶來的結果就是軟件質量的不可控。
4 很多軟件是很復雜的，而且是需要取舍的
為瞭方便用戶而引入的圖形化和操作互動，同時也是 bug 之源，但為瞭便利，我們隻能忍受，並盡可能降低 bug 的數量。除此之外，大型軟件中涉及到的許多工具，本身就不夠完美，但我們還得使用它們，比如網絡通信協議，同樣不完美，但我們不能等到完美那一天才上網。
5 不一定是真的有 bug
開發人員根據需求，原型圖進行編碼。這時候 bug 就出現瞭，畢竟經過這麼多環節，可能老板最初的意願，傳達到底下程序員手中已經完全變瞭味瞭。或許老板也不知道到底想要什麼，你先做一個出來給我看看。又或者即使符合老板的意思，但是跟市場，跟客戶真正想要的有又出入。就得不停的改瞭。反正寫代碼又不像蓋房子，蓋完瞭就不能拆瞭重新蓋。
你認為呢？
