為什麼互聯網巨頭的產品會有一些低級的 bug？

01-08

舉一些例子.
騰訊公司的QQ空間的好友動態里經常會無法顯示出好友的備註名稱,android客戶端的同一個activity(即頁面)你可以打開很多次,導致返回的時候按多次返回鍵.
阿里巴巴下天貓登錄頁面在firefox下兼容性不好,比如現在明明驗證碼沒有顯示卻讓我輸入驗證碼:

更令人震驚的是百度廣告聯盟,竟然網站竟然無法打開錯誤:
仔細看了看可能是拼寫錯誤,在網址前添加"u"之後可以打開但是圖片依然不顯示:
更離譜的百度移動聯盟首頁竟然是這樣滴:
Google雲端硬碟上傳文件夾亂碼:
知乎不算巨頭,但是說說一個吧:剛剛回答了一個問題,正在被知乎的編輯工具折騰得惱火又發現"發布"答案的按鈕竟然沒有了(大家可以看到我已經滾動到底部了):

這些互聯網巨頭的產品為什麼會有這些bug呢,難道是軟體測試員的問題?

我在百度的時候，某業務後端平台一周上線一次，qa數量比開發少，基本靠自己測試，大致沒問題就行了，一些edge case考慮不足時有發生，有時候臨上線了pm還叫你改這改那，出現bug是很正常的。能開發完就行了，還得忙著趕緊看看下周要做什麼呢。。。

在微軟開發網頁時，一個小功能修改，例如調整整個頁面字體大小，是這麼實現的。

第一周dev pm test一起需求評審。dev和test配比基本是1:1。dev做prototype，定開發方案，寫design。test寫test case。三方把需求講清楚後，需求是會被lock down的（之後pm不準再改了哦，要改就等到下個sprint吧）。

第二周dev開始開發，code review，check in。

第三周test開始測試，開bug。dev修bug，寫部署文檔，使用說明文檔等。

第四周pm在預測試環境中部署測試，之後在線上環境部署正式上線。

這一個月下來就改了個字體大小，最終代碼行數都不超過50行。

在百度時，我所在的組不需要code review，隨便我每天check in幾次，時間很緊，我開發也基本不寫注釋，反正這一塊都是我負責的，自己明白就行了。但我離職後，我估計維護起來就沒那麼容易了。

在微軟，我那個組code review是要由兩個sde approve才行的，有時候代碼甚至會被principle dev review，就算一個css的數值改動，都要按照schema約定寫上一大段注釋，如：這個change是修bug還是做task，bug或task的id，title等。。。check in的時候要關聯你的task或bug，這樣changeset就有對應的tfs item可以跟蹤了。這對幫助你理解他人的代碼以及他人理解你的代碼是很有幫助的，一目了然。

即使在微軟這種模式下，我們也很難避免一些live bug，但這些bug基本都是一些極端案例，重要級不是很高。

所以bug的出現完全就是單位人力投入不足造成的。不過我理解百度的做法，畢竟快速上線能為公司帶來利益，合理範圍內的bug是絕對可以容忍的。但是從程序員的角度來說，當然喜歡微軟的節奏了，其實往往第一個星期我就已經開發完了，之後三星期自己想研究什麼感興趣的都可以。

結果驅動。

你想要什麼就能得到什麼。

互聯網需要快速的驗證產品，快速的迭代，所以完美的質量不是優先順序最高的，不完美的產品也是可以忍受的。

題主你想想，簡化一下問題，假設一家互聯網公司每產出一行代碼產出一個能讓你看見的bug的概率是p，那麼至少產出一個bug的概率是

1-(1-p)^N

N是代碼數量

隨著N的增加，不管p有多小（總不可能是0吧?），你見到bug的概率都是100%

尤其是項目做到比較大的時候，質量控管再松點，那N都不用太大你就看到了

所以這個不在於公司技術怎麼樣（當然技術牢靠的公司，比如google，對p的把關非常嚴，會讓你能發現的bug少一些），你都會看見bug

況且上面大大簡化了實現一個大型項目的難度。通常一行代碼的p出了問題那麼接下來的很多代碼的p就大大增加了。比如說，你同事封裝好了一個庫，你以為無bug所以也不測試直接上來用，但是裡面會產生完全讓你沒預料到的bug，那麼你的代碼比起沒有用這個庫的時候，要更容易產生bug，產生一個叫cascading的效應。

混口飯吃不容易，莫要再截圖打兄弟們的臉了...

伺服器老是給我提一個問題。

對互聯網來說，出現 bug 從不修復的一個非常重要的原因是：

很多產品沒等 bug 修完就已經過時不再有用了。

無論什麼公司的產品都不可避免有一些bug，互聯網巨頭也無法例外而且還有可能更多，我猜想可能和以下一些因素有關：

1.網路環境多樣性

2.客戶端環境的多樣性

3.用戶使用習慣的多樣性

4.公司對產品質量的重視程度和開發/測試人員的水平

1、時間緊、任務急，領導催、產品催，能做出來就不錯了，哪有時間改bug。

2、巨頭的產品也分優先順序，後娘養的基本屬於自生自滅，不保證每個產品都是高質量的。

3、巨頭是由成千上百個產品組成的，可以細分到上千個產品經理，每個產品經理只負責自己那一部分，就會造成不同產品間聯調出問題。或者其中有一個產品有bug就會影響整個系統的功能。

4、某些看起來的小bug涉及到技術架構等技術問題，不是那麼容易更改的。

有兩種可能：不知道，知道沒修。

後者多種可能：在修還沒發布，優先順序不夠還沒排到，確認是問題但覺得不值得修，認為不是問題。

根本原因還是軟體研發水平不到，越是大公司問題越大，大公司病不只體現在花錢和開會上哦。

《Designing The Well-Tempered Web》中闡述了網站設計三大原則。CSDN對該文進行了編譯，其中提到「平均律」的概念：為了針對一系列不同設備設計出好的體驗，我們必須允許某些界面出現偶爾的不完美。我們必須做出小小的妥協，以保證我們的設計可以很好地適應其他的環境。

不過文章中提到的是界面缺陷，不算低級bug。只是覺得題主提到的這些bug可能也是發布時考慮了「平均律」和實效性。

原文Designing The Well-Tempered Web

隨著技術的進化，Web設計的藝術和技巧也在不斷進化。新的技術創造了新的挑戰，而新的挑戰要求新的解決方案。我們通常工作在未知領域，需要給出全新的解決方案。

考慮到有限的Web設計歷史，我們必須超越當前的領域去回答更有挑戰性的問題。為此，我們可以通過借鑒其他不相關領域的發展歷史，如音樂，從中尋求可以幫助我們解決問題的方案。下面將列舉一個18世紀早期關於巴赫的一個小故事。

巴赫和《The Well-Tempered Clavier》

1972年，巴赫完成了一部著作《The Well-Tempered Clavier》（《十二平均律鋼琴曲集》），分上下兩卷，每卷各有24首前奏曲與復格曲。現在它已被譽為西方音樂歷史中最重要作品之一。

在當時，為12個主要的琴鍵分別譜曲是完全不可能的。而巴赫卻從整體上為全部的12個音作曲。正是他的這套《十二平均律鋼琴曲集》，最終向人們證明了「十二平均律」是可以用來作曲的，而且其效果之美妙，以前的人們從未曾領略過。

在這個過程，所採用的解決方案是重新定義了「合調」的概念。通過修改一定的間隔，使每個琴鍵稍稍偏離完美的音調，從而產生一種調音系統，允許人們在所有的琴鍵上演奏出合調的琴樂。犧牲少量的個體品質以達到更完美的整體效果，被稱為「平均律」。

該案例雖與網站設計不相關，但目的是一樣的：使每個琴鍵都稍有缺陷，以便鍵盤整體表現完美。

不如說，Web的發布部署模式，可以讓公司對BUG的容忍度大幅度提升。

嘛，這就是不管怎麼樣都要去佔個坑，但佔了坑的拉的shi(t)是什麼連佔坑的人自己都不知道呀。那麼一不小心拉錯地方簡直再正常不過了。

既然是巨頭，所以一般來說系統龐大。產品組的同事每提一個bug，然後作為程序員要先去讓bug重現，然後看它跑的哪幾行代碼，然後看這幾行代碼寫的些什麼玩意(根據我自己實習的經歷，這個階段貌似最蛋疼)，想一想然後再去改代碼。好的，這個時候你在本地開發完成，測試通過，可以提交到團隊的測試環境了，然後有些情況就是，好幾個bug背後的代碼相互依賴，可能發生的情況就是你的同事 merge 的時候把你的代碼衝掉了，或者在中間插入了其他的代碼，然後又要想辦法重新改，或者說產生了潛在的新bug...

這樣一來，改個bug周期就會變得很長，迭代緩慢，所以，很有可能你說的這些問題人家早就發現了，程序員已經自己改好了只是還沒上線而已，

畢竟互聯網才發展了這麼些年，還很不完善

伺服器提了一個問題，我們正在緊張地撰寫答案...

沒有百分百的測試覆蓋率，只要是人寫出來的程序，做出來的產品，就會有bug。無須大驚小怪

催的緊啊，新功能開發還有bug修復，有時候一個人在兩個版本中。當然除了這個時間緊的原因，我也出現過一些低級bug，唉！這個自身問題，加強review是個防止低級錯誤的好方式，還有利於代碼能力的提升，高手review學到的很多。

有人的地方，就有江湖，和BUG

1、面向個人用戶的產品，重要的是能快速上線獲取用戶，只要不是十分影響使用的基本功能問題，用戶的容忍度還是比較高的，而且只要吸引的人比放棄使用的人多，就是賺了，有些小問題，快速迭代，進行修改就行了。

2、對於平台級的產品，就要求比較高了，比如QQ不能斷線、淘寶網站要能接入，但是互聯網公司一般是通過海量的伺服器容災來規避這種風險的，少量設備故障也能快速識別和恢復，對終端用戶不可知。

科比為什麼會傷退？

只要能用。——互聯網乃至整個信息科學領域的第一信條