程式設計師老在改Bug，就不能一次改好嗎？

AI科技大本營發表於2019-01-28
程式設計師

640?wx_fmt=jpeg

作者丨伍杏玲

來源 | 程式人生（ID：coder_life）


程式設計師的日常三件事：寫Bug、改Bug、背鍋。連程式設計師都自我調侃道，為什麼每天都在加班？因為我的眼裡常含Bug。

但是真的有這麼多Bug要改嗎？就不能一次改完嗎？

程式設計師聽這問題後要拍鍵盤了，還！真！不！能！


使用者使用場景的不確定性


在日常生活中，即便每個物品都有使用說明書，可一千個使用者就有一千種使用方式。例如用諾基亞手機砸核桃，用iPad當切菜板，所以說程式是確定的，但使用者的使用場景是不確定性的。

各種不按套路出牌的操作會給系統帶來挑戰，例如網上有個段子說：

一個人走進一家酒吧，要了一杯啤酒

一個人走進一家酒吧，要了一杯咖啡

一個人走進一家酒吧，要了0.7杯啤酒

一個人走進一家酒吧，要了-1杯啤酒

一個人走進一家酒吧，要了2^32杯啤酒 

一個人走進一家酒吧，要了一杯洗腳水

一個人走進一家酒吧，要了一杯蜥蜴

一個人走進一家酒吧，要了一份asdfQwer@24dg!&*(@ 

一個人走進一家酒吧，什麼也沒要 

一個人走進一家酒吧，又走出去又從窗戶進來又從後門出去從下水道鑽進來 

一個人走進一家酒吧，又走出去又進來又出去又進來又出去，最後在外面把老闆打了一頓 

一個人走進一家酒吧，要了一杯燙燙燙的錕斤拷 

一個人走進一家酒吧，要了NaN杯Null

一個人衝進一家酒吧，要了500杯啤酒咖啡洗腳水野貓狼牙棒奶茶 

一個人化裝成老闆走進一家酒吧，要了500杯啤酒並且不付錢 

一萬個人在酒吧門外呼嘯而過 

一個人走進一家酒吧，要了一杯啤酒 ';DROP TABLE 酒吧 

一個人跳進一家酒吧。 

一個人蒙著眼睛，倒退著走進一家酒吧。 

一個人走進一家酒吧，要了一杯美國啤酒，一杯德國啤酒，一杯比利時啤酒，一杯青島啤酒。

一個體重五百噸的人走進一家酒吧。

一個酒量五百噸的人走進一家酒吧。

一個酒量為零的人走進一家酒吧。 

一個人走進一家酒吧，點了一杯啤酒，一邊喝一邊用指尖把啤酒逼出體內。 

一個人來到一家酒吧門口，拿出電腦，敲了幾個命令，2^32 - 1 個測試工程師走進一家酒吧。 

一個人戴著墨鏡，手持兩把 Uzi 衝進一家酒吧，對著室內一頓掃射，然後要了一杯啤酒。 

一個人走進一家酒吧，要了一杯Nil，一杯Null和一杯None 

一個名叫exception的人走進一家酒吧，被丟了出來 。

我走進酒吧要了一杯">_ <”

我盜用老闆身份走進了酒吧進了後臺放了一瓶我自己的酒。

我走進酒吧在吧檯放了一杯' or 1=1。

最後酒吧炸了。

軟體設計中最大的現實是：設計難以完全覆蓋現實。

一個簡單的搜尋框，測試用例高達幾十個。可以說只要使用者在使用系統，系統就存在Bug。

而程式設計師在程式設計時只能按照需求與經驗覆蓋大部分使用者的使用場景，剩下的只能是見一個Bug滅一個。


需求的不確定性


之前有“AI都會程式設計了，要程式設計師幹嘛”的言論，造成很多程式設計師產生焦慮紛紛要轉行。

等等，說這話的人肯定沒問過產品經理。

網際網路公司的兩大謊言一是程式設計師說的“沒問題，上線吧”，二是產品經理說的“就按這個做”，現實是“我還要改幾十版哦”。

產品經理自己沒想明白需求要做成什麼樣子呢，在AI做出一個百分百正確無Bug的軟體前，它學會給產品拍磚的可能性會更大。

隨著產品不斷迭代，不斷增加的程式碼自帶Bug時，還可能會給原有程式引入Bug。有時候涉及底層程式碼的修改，一旦出問題，有可能會帶來多米諾骨牌效應。

還有時候是程式好好跑著，Bug從天上來。例如聖誕節阿里的Antd彩蛋Bug，又如在2005 年日本瑞穗證券的交易員輸入錯的股價，想撤銷可被系統拒絕，導致造成400億日元的損失。後來證實系統出Bug了，這個Bug是在2000年埋的。

所以很多公司會嚴格要求在程式修改後必須經過嚴格的迴歸測試，來驗證對其他業務流程有沒有影響。


程式設計師不是機器


程式設計師是人，不是機器，人做事是主觀判斷性去做的，再加上“稟賦效應”：心裡頭自動地給自己寫的程式碼添一層濾鏡，覺得自己寫的程式碼沒有問題，所以程式設計師總找不出自己的Bug。

這導致程式設計師日常的第四件事是：挖坑填坑。有人大手一揮，一大段程式碼不寫註釋，或業務方法不用公共定義，不拆分類，一個方法寫了一千行，從此沒人敢動這些爛程式碼。也有人默默地“感謝”前任給他有活幹，一點點地將坑填上。

還有對開發流程的漠視也是導致系統Bug多的原因。有開發心想“我只是改了兩行程式碼，不影響業務流程”，心想提給測試太麻煩了，便自顧上線了。

結果線上就出Bug了。

所以公司才設定各種軟體開發規範來減少Bug的產生，例如提測前開發之間的Code Review和需經過測試人員的測試才能上線。

程式不是一蹴而就地做出來的，Bug也不是一時半會能改完的。畢竟“寫程式不像是造一座橋，而是造一座城。”

（本文為 AI科技大本營轉載文章，轉載請微信聯絡原作者）


◆

公開課預告

◆


如何用AI技術為黑白老照片上色？本次公開課中，百度高階研發工程師李超將講述對抗生成網路相關，學術界的研究現狀和應用場景，以及GAN在百度視覺+百度PR+新華社合作的煥彩專案中的應用。


640?wx_fmt=png


推薦閱讀


640?wx_fmt=png

相關文章