臥槽，怎麼跑來跑去都不過。

臥槽，終於搞掂了，下一個BUG。

臥槽，怎麼跑來跑去都不過。

臥槽，這難不倒我呀，咦天快亮了。

當測BUG成為習慣的時候，難道還會因為發現BUG而內心波動？

剛入行：我曹，有bug，趕緊修，不修好今晚就不吃飯了。

大牛：我曹，這程式怎麼可能沒有bug，這不科學。

發現BUG有毛波動，哪個程式沒有BUG，問題是通宵加班還找不出BUG，或者一些不定時的隨時的BUG才讓人抓狂~

1.這不是我寫的

2.我沒問題啊 你電腦有問題吧

3.嗯 有可能因為#*?5*！#！：#～-。

臥槽(#ﾟДﾟ)，過不去，查霸哥，修霸哥，臥槽(#ﾟДﾟ)，還是不過去，然後再查霸哥，在修霸哥，臥槽(#ﾟДﾟ)還是沒解決！！(ノ=Д=)ノ┻━┻

告訴我吧！天啊，我的程式到底哪裡寫錯了？？？臥槽，這麼簡單的語法我錯了。不幹掉你（bug）勞資不吃飯了。恩。。。。這個bug可以用來幹什麼？如果只是簡單的閃退就不鳥你了（騰訊一貫作風）。。。。。

1、（晨會，領導通報發現線上有點問題）臥槽，怎麼可能，這部分我跑過的啊沒問題啊

2、開啟瘋狂debug模式，什麼情況，沒問題啊

3、啊～終於找到你了，就這小問題啊，解決了，今天心情好，晚餐價格高一個leave，

總而言之，排查時間越久，解決完越爽，

臥槽，你的bug,影響我進度了。。。

臥槽，都對的啊，怎麼會這樣？nullpointerexception? fuck....不說了，我要改bug了

（安卓程式設計師）遇到一個bug，趕緊把程式碼中輸出log的程式碼取消註釋，然後執行看logcat，之後就能發現是哪裡出了問題。

我一般發現bug都是。

哦，又出現bug了，很正常。

然後打電話喊兄弟：過來一下，請你出去玩。

然後就………

我只想說當測試的告訴我你這有個BUG的時候我的第一個反應就是，我擦，不可能啊，明明改過的，誰肯定動我程式碼了，沒道理啊！哈哈

當你做一件很複雜又很枯燥浪費時間的事情，當你欣喜的發現終於做完的時候，你發現了一個BUG，這時候心情可以說是崩潰的。 如果次數多了，估計你就真的崩潰了。我現在就在做軟體測試 ，而且還經常寫一些工作上的事，現在感覺自己老了似的，開始轉型了，會選擇寫一些總結而不是瑣碎，也許這是我以後當領導的徵兆吧。 程式設計師是善於思考的一個職業，做過這行的都知道，寫一個程式的過程都要經過構思、設計、寫程式碼。當然也分什麼樣的吧，小小的bug點幾下就搞定了，沒什麼情緒，大bug估計會崩潰吧，尤其需要改一大堆程式碼或者直接需要重寫的。

剛入門的會說，我靠，哪裡寫得不對？怎麼辦啊？稍微好點的會問怎麼打斷點啊？。入門一年可以寫點東西的說，在我那裡明明是好的，這肯定不是我的問題。寫了二年的會說，嗯，處理好了，下一個。工作三年的一般邏輯不會出大問題，會說，資料庫誰加了個欄位也不和我說一聲。工作四年的一般不會做聲，默默的把自己的和別人的都修復好。五年以上的做到小管理的會說，這誰誰誰，你這裡估計寫錯了趕緊處理下，不會？算了，我來。。。

對於bug這個事情，是常態。很多時間都是為了修復bug而存在。

但不管如何，遇到bug，不同的人有不同的心境。有人會想，怎麼還有bug，煩死了。而有的人卻高興的說，又發現了一個，我可以改變世界了

當然面對加班，熬夜的常態，更想是bug越少越好。

相對而言改bug比使用者改需求，強太多。

1.別人寫的程式碼有bug我操這個大撒比寫出這麼個爛程式碼，幸虧有哥這樣神一樣的存在才發現，哥真是救世主

2.自己寫的程式碼有bug

(1)執行很久

<1>別人發現這個程式執行很久了是不是真有bug啊，是不是你弄錯了啊，可以重現麼，什麼？可以重現，有尼瑪問題也不大，要不使用者早投訴了，瞧你那驚慌失措的樣子，真想吐你一臉狗屎

<2>自己發現這個bug隱藏的很深啊，還好哥犀利犀利，沒有被領導發現，今晚加個菜

(2)新上執行緒序

<1>別人發現這個程式剛上線還處於除錯階段，有bug很正常，誰的程式沒bug，連作業系統都有bug

<2>自己發現哥就是犀利，自己開發自己測試，看測試那幫撒逼什麼也不會幹，這麼明顯的bug都測不出來，真是一群廢物

其實寫程式的時候編寫程式碼只用5％的時間，剩下的95％都是在測試和修改中度過，除了一些比較罕見的BUG比較難以追蹤，處理起來都很有成就感，一般程式設計師對出現的問題都是很淡定的，最多也就是看到凌亂程式碼怒罵一聲握草。

1、發現別人寫的程式碼有bug

有bug？嗯，意料之中，這人水平不行啊，程式碼簡直辣眼睛，還是我厲害這麼快就發現了。

2、發現自己寫的程式碼有bug

是bug嗎？應該不能吧，我再看一遍。

嗯....這個bug隱藏的很深啊，還好我及時發現了，沒有被測試和領導發現，今晚加個菜

作為一名程式設計師，在開發的過程中免不了出現bug，只要是軟體，就不可能沒有bug。但是並不是所有的bug都可以被找到，如何減少bug的出現成為了程式設計師最為關心的問題。

寫程式碼之前一定要先思考，不要一上來就寫程式碼，寫完了之後發現這個介面和呼叫者使用場景完全對不上，然後就匆忙提交測試，測試發現bug後又胡亂的修改，結果導致了很多問題。當程式設計師們遇到自己或者是其他人埋下的邏輯炸彈，程式設計會變得很困難，我們天天在編寫邏輯炸彈，它們就在地表下靜靜地待著。

因此，編寫明確表達行為的程式碼，選擇有意義、準確、無歧義的符號名字，嚴格執行命名方案，不要用不同的單詞描述同一個事物，所以思路清晰是程式設計的第一要務。

註釋要有理有據，切莫

我勒個去，為什麼又出現了Bug!!!

可怕的不是說出現了一個把個可怕是你改完了這個bug又出現了其他的bug,改完一個又一個,bug改不完。

對於已經上線執行的程式碼

如果被發現有一個bug，事情跑了一段時間，立馬會感覺很非常的慌張。怎麼回事？竟然會有大哥我去湖經有沒有影響到已有的功能，有沒有產生一些惡劣影響，比如說影響到資金。影響到使用者體驗還好說，如果你資金流失那就很麻煩了。然後趕緊想辦法怎麼改怎麼改怎麼改，想想怎麼應對領導，怎麼把這個問題讓別人一起來承擔，通常來說，bug的出現一方面是由於追劇，主要原因是由於開發的問題，另一方面是在測試過程中沒有測試充分，或者是說在溝通測試案例的時候沒有考慮周全，你自己單元測試的時候也沒有考慮周全。

對於開發完成正在測試的功能

怎麼辦如何？如何跟測試說一下，這不是個bug呢！如何解決一下他讓測試不提缺陷？哎呦，趕緊想趕緊想辦法解決這個bug，自己當時怎麼就沒有想到這點呢。馬上就臨近上線投產了。趕緊解決掉它，不然影響正常的上限又要被老闆叼了。

當發現了其他人寫的bug

某某某怎麼這麼坑，這麼簡單的功能，竟然會寫出一個bug。趕緊跟。相關人說一下，看看想一個解決辦法。來修復這個bug。

其實我覺得bug就是對自己。自己能力不足的一種提示。隨著你，寫的bug並修復bug。那麼你的能力逐步提升，寫出bug的可能性也會逐漸降低。有很多bug是由於其他一些因素影響到，就比如說你的程式碼，由於資料庫的歷史資料影響到產生了一個吧哥，這是在你一開始沒有考慮到，而是隨著資料量的增大增加開展顯現出來。這樣可以讓你在以後的開發過程中能夠考慮的更加周全，更加周密，能夠寫出更高質量的程式碼。

任何程式，bug是一定存在的，程式設計師必須要正視和承認這點事實，因此，當別人發現並向你指出程式有bug時，正確的態度是承認“可能真的有”bug，千萬不要馬上否認。承認bug的態度，能夠體現一個程式設計師的素質。

程式設計師收到bug報告的時候，應該採取的做法是：

1.聽清楚現象報告和描述，根據自己程式的邏輯和實現細節，思考這種現象是否程式設計疏漏所致。你必須清楚自己寫的任何程式碼的運作細節，我很反對黏貼別人程式碼搬開源庫的拿來程式設計師，出了問題，根本不是他們自己可以解決的，你能解決人家提供的開原始碼bug不如自己直接寫了，你拿過來就一定是自己寫不出，把程式執行的正確性寄託在別人無錯上，但人家既然開源可不會為你的工作負責，又沒收你錢，說開源了自己可以改程式碼那是騙bc的，有空去吃透那些程式碼自己也會寫了，你一定是自己不會又不想付錢才熱衷開源。

2.若不能在邏輯上找到問題所在，就必須跑到現場，把錯誤重現出來，只有能夠重現的問題，才有解決的方向，而這種問題沒能在你的開發機上測試出來，就一定是你疏忽了實際的環境，或者是使用者有你沒考慮到的操作。

3.bug必須在邏輯上從根本解決，修復是要理論證明不會再出現類似bug的。不能靠碰，用過橋法是沒用的，繞開此處，不等於別處沒有同樣的問題，沒找到真正的根源，就不叫成功修bug。無論是找根源還是修復問題，都是靠程式邏輯，不能頭痛醫頭腳痛醫腳，不熟悉程式邏輯，就不知道該在哪設斷點和檢查什麼資料，旁觀一個程式設計師是怎麼查改bug的，也能看出是什麼水平。