開發好的程序，為什麼會有bug？

一天，有個甲方問我：「開發好的程序，為什麼會有bug？」 我雖然心裡暗暗覺得這真是個stupid的問題，但是我還是能夠理解甲方的感受----「我付錢讓你們開發的軟體，為什麼不做成完美無瑕的再給我？更鬱悶的是，為什麼日後出了問題找你們修，還要額外收費？」

嗯~ 出於對我們所提供服務的負責態度，我還是有必要跟甲方大大把這個問題解釋清楚~

我先解釋下「為什麼交付後，軟體還是會有bug？」

正面來說，就是軟體是由一行行的代碼組成的。程序員在編寫這麼多的代碼過程中，難免會在邏輯上或者輸入上有一些疏漏，這些疏漏就是bug了。

舉個例子來類比的話，程序員寫一個軟體類似於作家寫一本書。即便經過多人審閱，一本書出版後還是難免有錯別字、邏輯上的錯誤、情節上的不合理等。同理，即便上線之前軟體經過層層測試，最後交付之後也難免還是會有一些沒注意過的細節問題。

錯誤其實是永遠都會有的，我們需要做的只是「盡量」將它控制到最小。

再延展一點說，可以說你日常用的每一個軟體，每一款APP都是有bug的，只是你沒有碰到有bug的地方，或者你碰到了但是你沒注意罷了。微信、淘寶也不例外哦。

多羅嗦幾句，其實所有的技術都是大概率有效，而不是100%有效

工廠標準化、流水線生產，你覺得生產出來的東西應該都是一樣的吧？不，只是大概率一樣，還是會有很多次品，所以工廠生產產品很重注一個叫「良品率」的指標，這個指標就是說「大概率有效」裡面的大概率有多大。

產品生產出來之後還要經過質檢，質檢之後的產品應該都沒問題了吧？不，質檢都是抽樣質檢，比如1萬件產品裡面檢查100件，然後計算「良品率」，「良品率」達標則全部產品過關，也就是說有9900件產品其實是沒有檢查過的，只是根據估算應該大體沒什麼問題。（當然檢驗出來不合格的那幾個一定會扔掉）所以每1萬個消費者里可能有一個人會買到次品。

甚至通過了質檢的產品，也有出現整體設計問題的可能。因為質檢的標準是根據以前的經驗制定的，可能沒有考慮到近期出現的新情況，同時即便是舊有的情況，質檢標準也不會面面俱到地都檢查到，質檢都是只檢查若干個關鍵指標。所以我們在新聞上才會時不時地聽說某個車企又召回了多少量某型號的汽車。

每一個環節都不能保證是100%沒有問題的，也就是說，無論生產什麼，都不能保證每個產品都達標，商家能做的就是在你買到次品之後給你換一個好的。

說到這裡，是不是感覺生活頓時沒有安全感了？我家的房子會不會質量不達標，突然倒塌了啊？走在馬路上，會不會馬路質量不達標，突然出現個大窟窿啊？你很難碰到，但是不得不說這有可能，只是可能性非常小。相比於這些致命性的問題，你遇到的更多的產品不達標通常都是「我的桌子商家說是120cm高，但是實際上只有118cm高」，「我的軟體承諾支持Android, IOS兩個平台，結果Android中魅族的手機使用時會出問題」等等，大多數不合格、不達標，都是可以「忍受」的小問題。

其實世界上本沒有100%的安全，天上掉下不明物體砸死無辜路人的故事也是不勝枚舉的。所以，無論什麼產品，廠商的職責都是降低風險到最低，但不是消除風險，因為「消除風險」本不科學。

整個世界都是如此，軟體開發也不例外。所以，也請各位甲方大大不要再苛求程序員寫出「完美無瑕」的軟體了。如果哪個程序員承諾自己的軟體是「毫無缺陷」的，那他不是自大，就是騙子。

「我們可以接受出現問題，但是為什麼你們修復問題還要收錢？」

首先，嚴正聲明，我司完成的項目，都是有三個月免費質保的，頭三個月修復都是不收錢的！

那為什麼三個月後要收錢呢？

這裡，我先拋出一個事實：即便你不更改軟體的代碼，你的軟體也不能保證不會突然壞掉。原因是，現在的軟體都是和其他軟體或者服務配合著完成功能的，軟體都不是完全互相獨立的，其他的軟體或服務如果發生了變動，就有可能會導致你的軟體「壞掉」。拿目前最火的微信小程序來說，如果你實現了一個自動獲取用戶昵稱和頭像的功能，那麼可以預計未來幾個月你這個功能即將失效了，因為微信馬上就要取消自動獲取用戶昵稱和頭像的功能了，改為要求用戶明確地點擊按鈕，才能獲取昵稱和頭像。你的程序可能什麼都沒改，日後新用戶的昵稱和頭像就突然獲取不到了。

也就是說，你的軟體壞掉，並不是我們開發人員的錯誤，而是這個軟體所依賴的其他軟體做了改動而導致的。因為這是一個沒有預料到的改動，開發團隊需要為此投入沒有預料到的人力成本，所以這部分改動需要收費。

還有一種可能，是你的應用規模變大了導致軟體壞掉了。同樣是實現即時通信的功能，做一個給100人用的產品，和做一個給100萬人用的產品，其中的實現成本可能有數十倍的差別。軟體交付後，如果您的軟體使用量迎來爆髮式的增長，那麼很可能很快你的軟體就需要改版重做了。你可能會問，難道不能一開始就設計為支持100萬人的產品么？當然可以，不過您就要為100萬級別的架構支付對應的項目費用了，這可能是非常貴的。對於絕大多數的甲方來說，做一個規模合適、成本不貴的系統，才是最明智的選擇。等項目用戶量大了，再做改版，畢竟這個時候你心裡更加確定投入這麼多錢是值得的了。

這種情況下，為適應新的規模帶來的成本，是沒有考慮在最初的外包合同中的，所以這部分適應性改動是需要額外收費的。

另外，由於有3個月的保質期，所以實際上3個月後純粹的遺留bug其實很少見的。這時候甲方如果再找技術團隊要求修改bug，90%的情況是甲方使用不當，或者誤操作導致的系統故障。這類故障本身不是技術團隊的錯誤，但是發現錯誤、重現錯誤、調試錯誤卻要消耗大量的時間（有時候找問題所在要一天，修改bug只要一分鐘）。如果是免費的，甲方無休止地詢問，技術團隊也是承擔不起的。所以才會有3個月後，bug修復都是需要單獨收費的規定。

總結加廣告

說了這麼多，也無非是想讓甲方大大們體諒一下程序員們的處境。人非聖賢，孰能無過。程序員和bug的戰爭是無休無止的，請甲方大大們多給程序員一些耐心，讓世界多一份溫暖~

嗯，說了這麼多，順便推銷一下我們自家的外包服務吧。我們的外包服務後台完全基於Python，希望能夠幫助各位甲方大大實現自己的業務需求，並為甲方大大們提供周到專業的外包服務。

點擊下方小程序，進入首頁點擊「估算價格及下單」，提交你的研發需求，我們的工作人員就會聯繫您哦~

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！