酷播亮新聞
文章摘要： 作為一枚高智商程式媛經常會被甲方爸爸diss：「錢都交了為什麼開發好的軟體還會出問題，就不能完美無瑕的交付給我？更鬱悶的是，為什麼日後出了問題找你們修，還要額外收費？」
作為一枚高智商程式媛經常會被甲方爸爸diss：「錢都交了為什麼開發好的軟體還會出問題，就不能完美無瑕的交付給我？更鬱悶的是，為什麼日後出了問題找你們修，還要額外收費？」
嗯~ 出於對我們所提供服務的負責態度，我還是有必要跟甲方爸爸把這個問題解釋清楚~
我先解釋下「為什麼交付後，軟體還是會有bug？」
正面來說，就是軟體是由一行行的程式碼組成的。程式設計師在編寫這麼多的程式碼過程中，難免會在邏輯上或者輸入上有一些疏漏，這些疏漏就是bug了。
舉個例子來類比的話，程式設計師寫一個軟體類似於作家寫一本書。即便經過多人審閱，一本書出版後還是難免有錯別字、邏輯上的錯誤、情節上的不合理等。同理，即便上線之前軟體經過層層測試，最後交付之後也難免還是會有一些沒注意過的細節問題。
錯誤其實是永遠都會有的，我們需要做的只是「儘量」將它控制到最小。
再延展一點說，可以說你日常用的每一個軟體，每一款APP都是有bug的，只是你沒有碰到有bug的地方，或者你碰到了但是你沒注意罷了。微信、淘寶也不例外哦。
多羅嗦幾句，其實所有的技術都是大概率有效，而不是100%有效。
工廠標準化、流水線生產，你覺得生產出來的東西應該都是一樣的吧？不，只是大概率一樣，還是會有很多次品，所以工廠生產產品很重注一個叫「良品率」的指標，這個指標就是說「大概率有效」裏面的大概率有多大。
產品生產出來之後還要經過質檢，質檢之後的產品應該都沒問題了吧？不，質檢都是抽樣質檢，比如1萬件產品裏面檢查100件，然後計算「良品率」，「良品率」達標則全部產品過關，也就是說有9900件產品其實是沒有檢查過的，只是根據估算應該大體沒什麼問題。（當然檢驗出來不合格的那幾個一定會扔掉）所以每1萬個消費者裡可能有一個人會買到次品。
甚至通過了質檢的產品，也有出現整體設計問題的可能。因為質檢的標準是根據以前的經驗制定的，可能沒有考慮到近期出現的新情況，同時即便是舊有的情況，質檢標準也不會面面俱到地都檢查到，質檢都是隻檢查若干個關鍵指標。所以我們在新聞上纔會時不時地聽說某個車企又召回了多少輛某型號的汽車。
每一個環節都不能保證是100%沒有問題的，也就是說，無論生產什麼，都不能保證每個產品都達標，商家能做的就是在你買到次品之後給你換一個好的。
說到這裏，是不是感覺生活頓時沒有安全感了？我家的房子會不會質量不達標，突然倒塌了啊？走在馬路上，會不會馬路質量不達標，突然出現個大窟窿啊？你很難碰到，但是不得不說這有可能，只是可能性非常小。相比於這些致命性的問題，你遇到的更多的產品不達標通常都是「我的桌子商家說是120cm高，但是實際上只有118cm高」，「我的軟體承諾支援Android, IOS兩個平臺，結果Android中魅族的手機使用時會出問題」等等，大多數不合格、不達標，都是可以「忍受」的小問題。
其實世界上本沒有100%的安全，天上掉下不明物體砸死無辜路人的故事也是不勝枚舉的。所以，無論什麼產品，廠商的職責都是降低風險到最低，但不是消除風險，因為「消除風險」本不科學。
整個世界都是如此，軟件開發也不例外。所以，也請各位甲方大大不要再苛求程式設計師寫出「完美無瑕」的軟體了。如果哪個程式設計師承諾自己的軟體是「毫無缺陷」的，那他不是自大，就是騙子。
「我們可以接受出現問題，但是為什麼你們修復問題還要收錢？」
那為什麼修改bug要收錢？
這裏，我先丟擲一個事實：即便你不更改軟體的程式碼，你的軟體也不能保證不會突然壞掉。原因是，現在的軟體都是和其他軟體或者服務配合着完成功能的，軟體都不是完全互相獨立的，其他的軟體或服務如果發生了變動，就有可能會導致你的軟體「壞掉」。拿目前最火的微信小程式來說，如果你實現了一個自動獲取使用者暱稱和頭像的功能，那麼可以預計未來幾個月你這個功能即將失效了，因為微信馬上就要取消自動獲取使用者暱稱和頭像的功能了，改為要求使用者明確地點選按鈕，才能獲取暱稱和頭像。你的程式可能什麼都沒改，日後新使用者的暱稱和頭像就突然獲取不到了。
也就是說，你的軟體壞掉，並不是我們開發人員的錯誤，而是這個軟體所依賴的其他軟體做了改動而導致的。因為這是一個沒有預料到的改動，開發團隊需要為此投入沒有預料到的人力成本，所以這部分改動需要收費。
還有一種可能，是你的應用規模變大了導致軟體壞掉了。同樣是實現即時通訊的功能，做一個給100人用的產品，和做一個給100萬人用的產品，其中的實現成本可能有數十倍的差別。軟體交付後，如果您的軟體使用量迎來爆發式的增長，那麼很可能很快你的軟體就需要改版重做了。你可能會問，難道不能一開始就設計為支援100萬人的產品麼？當然可以，不過您就要為100萬級別的架構支付對應的專案費用了，這可能是非常貴的。對於絕大多數的甲方來說，做一個規模合適、成本不貴的系統，纔是最明智的選擇。等專案使用者量大了，再做改版，畢竟這個時候你心裏更加確定投入這麼多錢是值得的了。
這種情況下，為適應新的規模帶來的成本，是沒有考慮在最初的外包合同中的，所以這部分適應性改動是需要額外收費的。
另外，由於有服務的保質期，所以實際上純粹的遺留bug其實很少見的。這時候甲方如果再找技術團隊要求修改bug，90%的情況是甲方使用不當，或者誤操作導致的系統故障。這類故障本身不是技術團隊的錯誤，但是發現錯誤、重現錯誤、除錯錯誤卻要消耗大量的時間（有時候找問題所在要一天，修改bug只要一分鐘）。如果是免費的，甲方無休止地詢問，技術團隊也是承擔不起的。所以纔會有服務保質期，bug修復都是需要單獨收費的規定。
說了這麼多，也無非是想讓甲方爸爸體諒一下程式設計師們的處境。人非聖賢，孰能無過。程式設計師和bug的戰爭是無休無止的，請甲方爸爸多給程式設計師一些耐心，讓世界多一份溫暖~