1樓：大頭屁
現在的軟體BUG越來越多，全亂套了，就像windows 10一樣，BUG好像改不完的樣子，真不知道怎麼回事，到底能不能好好設計好？
2樓：
那你得找乙個全知全能的神，對系統所有細節每乙個變數時時刻刻都瞭如指掌，那玩意兒不會犯錯。另，所謂bug，換個角度看就是feature。
3樓：憤怒的小野驢
健身房老闆要設計乙個門禁系統，平時門都是關著的，來了顧客就把門開啟。程式設計師花了三個月研發出來了。
過了幾天，老闆：我只想迎接我們的顧客，但是很多人點了外賣往裡面送，嚴重影響健身房風氣，你改一下系統，把穿藍色衣服的餓了嗎小哥都關在外面。
過了幾天，老闆：你的系統把我們穿藍色衣服的會員都關在外面了。改一下，把穿藍衣服帶口袋的都關在外面。
過了幾天，老闆：我們有的使用者穿著藍衣服帶著自己的洗漱用品來健身房也被關在外面了，再改一下，我們的顧客都是有好身材的，把穿藍色衣服帶口袋的胖子關在外面。
哆啦A夢：MD，這個門有bug，不讓我進！
4樓：胡李輝
程式和所有別的東西都有乙個公理：
所有結論都是有範圍的，超過範圍就可能出現錯誤。
程式永遠都有BUG，不僅僅可能是開發的時候所設想的範圍比實際範圍更小，更加是因為對於程式來說這個範圍從來不是一成不變的，如果這個範圍出現了變大，自然就可能會出現BUG。更別說程式之間如果存在關聯性這種BUG是會引發連鎖反應的
5樓：黃海吉
bug的出現來自於多方面的，不見得一定是程式設計師的資質問題。比如說比爾蓋茨，比如liunx之父等等大佬，他們寫的專案同樣也會出bug。
6樓：商道隱
必然的。
任何人類的思維活動必然都會有瑕疵。程式有bug所以才產生了駭客。即使連作業系統這種底層的程式都有bug。
這個往深裡面說了，就是有陰必有陽，陰陽相生。我不繼續神棍了。
7樓：
軟體是多人合作的，合作就肯定有不同的思維，不同的思維就導致，銜接的時候各種BUG，而且大家的技術水平不同，未知的事情太多。除了個人本身因素，還有外部不確定因素。bug是無法杜絕的，除非什麼都是自己親手做的。
自己親手做的也可能出現bug，所以合作的bug就更多了。
問世間BUG為何物，非人為能杜絕的
8樓：two tigers
誤差算不算是 bug ？
然而誤差是絕對存在的。
假如你想盡量寫出來乙個基本上沒有什麼問題的程式，考慮到所有的事情，你的程式會變得又臭又長。
9樓：囧囧
如果有人從幼兒園到碩士博士畢業不寫乙個錯別字、考試客觀題全滿分，那麼這人有可能寫程式不出BUG，注意，也僅僅是有可能。
所以問題來了：全世界能找出幾個這種神仙？人家看得上你那堆破事不？
所以，必然出BUG。
10樓：
若編譯器本身有錯，傳統上排查比較困難。目前在一些對軟體質量要求極高的領域，已經開始使用形式化驗證技術，可以保證編譯過程自身正確。
形式化方法對軟體開發的挑戰：一些歷史與現實 - qzy的專欄 - CSDN部落格
11樓：Xi Yang
基於形式論證的開發工具，可以做到徹底沒有bug（除非開發工具自身的bug）。他會證明這一點。但限制極大：
基本沒人會用這東西。專案會很難招人。
你的功能、邏輯必須高度清晰且固定。
這類工具估計不太可能用現有的各種庫，所以你能做的事情也是受限的。
它主要用在一些控制軟體裡。
12樓：乙隻小憶兒
這個問題就像：設計師改設計是水平低了還是必然狀況？
我敢說就算當今設計大師都不能每次都是一稿過，他也需要改動優化自己的設計稿吧，
高手能做到盡可能的規避問題，減少問題出現的機率，而不是杜絕問題。
當然如果是顯而易見不必要的錯誤，那就是水平和態度問題。
13樓：
不說程式，現實當中又有幾件事情是萬無一失，絕對可靠？沒人能保證吧；
出門散個步還有可能被天上的隕石砸死，吃個飯也有被噎死的，誰敢說沒有這種可能？
程式自然也不例外，要不然幹嘛設計try catch等各種異常處理。
不過，具體到每個程式上，bug的多少和刁鑽程度，自然和程式設計師的設計水平是有直接關係的。
做同樣的程式，不同水平的程式設計師，效果是不一樣的。
當然不光是和程式設計師本人的水平，如果是多人合作的專案，管理水平和軟體工程設計也很重要。
14樓：彪大人
之前看到過有人發明了乙個抄寫機械人，就是通過攝像頭識字然後不是印刷是一筆筆寫下來字的機械人。機器嘛，抄寫的速度的確是快的，但是！！！！！！他居然也有抄錯的！！
所以你說bug是必然的嗎？
15樓：陳曉
一般都是程式設計師水平太差導致的，這種情況下，業內的解決方案一般都是殺一兩個程式設計師祭天就行了。
這也是為什麼很少有超過40歲的程式設計師的原因之一。
16樓：RaiderOnDit
必然的啊。但凡是兩腳獸寫的東西，總會出錯。無論是什麼語言，什麼語境，無論是程式還是文稿。
無論是錯別字還是狗屁不通…無論你改多少次，扔到一旁過一年再看，還是能看出錯來。識別錯別字，IDE比人眼強。但是識別狗屁不通，還得是人。
畢竟軟體目前還沒有思想，不能理解目的、意義、思路這些東西，只是機械地執行語法正確的語句。人發現了的問題，可能會得到修整。但是這東西也會被不同的人從不同的角度去讀，總有之前沒發現的問題。
17樓：Sun Winter
今天客戶要修改ui，問要改成什麼樣的，人家給了我一種顏色……乙個包含乙個大panel，數十個小panel，還有大量table、tab、chart的ui，就給一種顏色，你說這齣了bug是怪誰
18樓：花萼橫江
經驗豐富的程式設計師可以避免大多數的技術性bug，但對於業務性/系統性的bug依然無能為力。
解決業務性的bug，需要專案初期就考慮萬全，但通常受限於管理者的經驗和精力，實際中很難做到。
解決系統性的bug，需要系統的公升級換代能夠做到向後相容。比如作業系統sdk能保證相容性公升級，相關軟體就能保證良好執行，否則必然出bug。
19樓：簡大山
世界上不存在沒有bug的程式，最多只能將bug控制在一定範圍之內。最簡單的程式hello world,在一台機器上執行沒問題，誰也不敢說在另一台機器沒問題，機器的硬體和環境不同，同樣的程式也可以出錯。
20樓：
怎麼一堆程式猿說bug正常，不說自己水平問題？那麼產品狗出了幾個bug，要修改需求，很多程式猿就各種不樂意了？
你們罵，我先逃了
21樓：旋鈕
程式BUG本質上屬於一種產品質量問題，所以並不是只有程式才會有質量問題，而是絕大多數產品都會有質量問題，要想質量高可以，高投入高成本高監管，像航天工程那樣，保證高可用~但依然不是0故障，究其原因就是人類本就不完美，大多數東西湊合能用就得了，哪那麼多完美。
22樓：
在刀耕火種的時代，人肉程式設計寫程式的落後工作方式，必然帶來bug，因為人的能力是有限的，生產工具是原始的。
幸運的是，人工智慧時代已經到來，隨著神經網路人工智慧自動程式設計技術逐步走向成熟，人工程式設計即將被淘汰。人工智慧編寫的程式質量可以輕鬆與經驗豐富的專業程式設計師團隊媲美，而且不會有人腦時不時走神想歪產生的錯誤，質量非常高。可以確定，程式中滿是bug的時代即將成為歷史。
23樓：starsea
上帝：我可以滿足你乙個願望。
程式設計師：我希望在有生之年寫出乙個沒有bug的程式！
上帝：... ...
程式設計師獲得了永生... ...
24樓：skyfackr
對於越複雜的程式，人越多，bug越容易出現
除非是helloworld等級的程式，bug是常有的，有的時候輸入法都能導致bug，或者是錯字
除此之外，由於平台指令集，硬體不同都有可能導致無法預估的錯誤
25樓：
這是電腦的水平有限導致的。
比如你可以跟乙個人說，去那邊的桌子上給我拿一支筆過來，基本都不會搞錯。
但是如果你要電腦去拿一支筆，首先你要給電腦定義什麼是筆，然後定義什麼是桌子，什麼是上面，等等。
如果桌子上沒有筆，人會主動說：沒有筆！——你去抽屜裡找找！
電腦的話直接丟擲異常，你得提前告訴電腦沒有筆怎麼辦——找找抽屜的話還要定義什麼是抽屜。
26樓：左公民
以前想過幹嘛的時候，以天生不靠譜的家族遺傳，第乙個pass掉學醫，我整死人應該很容易，各種需要很少犯錯咱也幹不了。寫程式我知道大家都在錯，容忍度很高，一混好多年，結果發現比我爛的一大把。
程式有bug正常，手術刀留肚子裡，飛機少個螺絲，機房裡飛進乙個人蛾子（bug之母）。好的工業化產品，原料可靠，穩定的工藝流程，完善檢測機制，好的容錯機制，可以有高可用性。軟體這玩意要搞好，可以扯皮的點太多；但是只要設計合理，磨一磨都能達到比較高的可用性，大家一起努力就行。
不打磨，用完就扔也可以呀
27樓：xwyam
那些射擊的運動員無法每次都射10.9環是必然出現的還是自身問題
那些職業撞球手不能每球都進是必然出現的還是自身問題
題主考試沒得滿分是必然出現還是自身問題
28樓：一人之下
只能說是正常的吧
程式bug不僅僅程式水平問題，也涉及到產品的需求設計，程式設計師對產品的需求。軟體的複雜度。多人協作分工對專案的影響。
29樓：潘敬華
程式複雜度 - BUG程度 = log(程式設計師水平 * 開發時間)
程式不是必然會出BUG，比如寫個Hello World就很難寫出BUG來，再爛的程式設計師(不是假冒的或故意的)，也休想寫出來BUG。
30樓：我是傳奇
這個怎麼說呢…我覺得還是程式設計師的水平決定了bug的嚴重性以及數量，但這不是唯一，也不是最重要的原因吧！
比如遊戲裡面的輸入框的處理（度娘了解下負一 ）本身這個bug對遊戲的正常執行沒有任何影響但是被玩家利用。
程式對各種作業系統，對各種硬體的相容性，第三方提供的SDK，類庫本身自帶的bug，並它們對硬體或作業系統的相容性等各種原因也會成為出bug的原因，再加上工程量太大，費時間，燒錢等原因某種程度上也是有一定的影響。
總結 出bug是必然的，也是和程式設計師的水平，經驗有直接的關係，但是這不是唯一的原因，各種原因五五開吧。
不喜歡勿噴！
31樓：孤狐無悔
程式出現bug，是開發人員（包括程式設計師、程式設計師、測試員，專案經理等）總體水平有限導致的。但是，考慮到專案的複雜性，沒有專案組能保證乙個商用規模的程式完全沒有bug，所以出現bug是必然的。
針對bug這一話題，大多數成熟的專案組的目標都是：
1、程式沒有嚴重bug；
2、沒有頻繁發作的輕微bug；
3、若發現bug可以在最小影響範圍內修復。
而不是「完全沒有任何bug」。
為此，在開發時有額外的目標：
4、Bug可以被盡早發現；
5、Bug可以被盡可能多地發現；
為了實現以上目標：
一、測試階段（Test）：
6、完善的測試方案可以確保1、2、4和5；
7、足夠的測試時間可以確保6的切實執行；
8、專業的測試人員可以提高6的完善程度；
9、招募使用者的大規模測試（公開測試和內部測試）可以確保1、2和5，補足測試方案的不足之處；
二、除錯階段（Debug）：除錯階段其實是實現（程式設計）階段的一部分：
10、部分的測試方案可以應用在此階段；
11、充足的除錯時間可以確保1、2、4和5；
12、足夠水準的程式設計師可以確保3，水準不夠的程式設計師會容易在修復過程中能夠產生更多bug。
三、實現階段（Implement / Coding）：
13、測試用例（Test Case）可以確保4和5；
14、充足的開發時間以完成13；
15、良好的程式設計實踐（Practice）可以確保1、3、4和5，可以確保更有效率的6、10和13；
16、足夠水準的程式設計師可以確保1、2和4，減少6和10的所需的時間；
17、足夠數量、足夠水準的程式設計師可以加快開發，以確保為6、9、11和14的留有足夠的時間。
四、設計階段（Design）：
18、盡可能減少後期的改動，而後期改動很容易產生bug；
19、良好的設計可以確保3、4、5、6、10、13和18，同時可以提高17；
20、足夠的設計時間以確保19；
21、足夠水準的程式設計師可以確保19
22、及時與客戶溝通以確保18；
五、需求分析階段（Requirement Analysis）：在某些專案同時也是銷售階段（Sale）
23、良好的需求分析可以幫助18、19和22；
24、足夠水準的需求分析員或銷售員可以確保23；
25、足夠的需求分析時間確保23；
六、專案管理 ：
26、足夠的資金預算可以確保8、9、12、16、17、21、24和25；
27、足夠的時間預算可以確保7、9、11、14、20和25；
28、足夠水準的專案經理可以確保26和27，同時能夠理解以上全部的必要性，在無法達成以上條件時，能夠合理的取捨；
七、公司管理：
29、公司有完善的制度來支援以上全部；
30、公司文化支援高質量的專案；
31、公司有足夠的軟硬體設施來支援以上全部；
32、有足夠的資金可以支援26、27、28、29、30和31；
總結：花錢花時間，就能減少bug。
出現人這類智慧型生物是必然的嗎？
賀啊威 雖然我們的出現是偶然，但是智慧型生物的出現是必然。墨菲定律是 如果事情有變壞的可能，不管這種可能性有多小，它總會發生。其實就是給予大資料，所有的可能都會發生。從我們的現在存在可以證明智慧型生物是可能的。那結合兩者得出的答案就是 智慧型生物可以存在，而根據大資料定律，智慧型生物的存在將會發生，...
軟體測試員電腦上出現BUG但是在程式設計師的電腦上重複同樣的步驟卻不能重現該怎麼辦？
1 首先問題出發點在於測試確實證明有問題 2 提單跟蹤 3 找復現條件 4 如果長時間無法復現，且是非關鍵問題，暫時關了不管，等出了再說5 無法復現，且是影響功能的關鍵問題，協調當時的測試環境和人員復現定位，測試環境能出，將來使用環境也一定能出，要有填坑的覺悟。總結，這事就是能力問題，測試開發對產品...
出現過地鐵列車進錯站台的情況嗎？可能出現嗎？
盤石龍 一般情況下是不會的，地鐵執行一般都是通過電腦控制的。道岔的改變 訊號的顯示 機車的調速等等這些大部分都是電腦計算去控制，所以地鐵出現1號線站台進入了2號線列車這種情況是微乎其微的。 已登出 不存在的，中國大陸的地鐵線，紅的線路跑紅車，綠的線路跑綠車。借調有，但極少發生。寧可少發車，不發車，也...