程序員發現 Bug 的時候是怎樣一種心境？
手頭項目發現bug的時候，我總是非常抓狂
1.別人寫的代碼有bug
我操這個大撒比寫出這麼個爛代碼，幸虧有哥這樣神一樣的存在才發現，哥真是救世主
2.自己寫的代碼有bug
(1)運行很久
&<1&>別人發現
這個程序運行很久了是不是真有bug啊，是不是你弄錯了啊，可以重現么，什麼？可以重現，有尼瑪問題也不大，要不用戶早投訴了，瞧你那驚慌失措的樣子，真想吐你一臉狗屎
&<2&>自己發現
這個bug隱藏的很深啊，還好哥犀利犀利，沒有被領導發現，今晚加個菜
(2)新上線程序
&<1&>別人發現
這個程序剛上線還處於調試階段，有bug很正常，誰的程序沒bug，連操作系統都有bug
&<2&>自己發現
哥就是犀利，自己開發自己測試，看測試那幫撒逼什麼也不會幹，這麼明顯的bug都測不出來，真是一群廢物
第一家公司的架構師是微軟的fans，只要是微軟的技術，不管多非主流，都要在產品里用一下。
那時我們做了一個訂票系統，很多旅行社在用。一個vc++程序，用hta啟動，jscript配置環境，c++里嵌套ie控制項，裡邊跑html，html裡邊跑activex，activex裡邊跑wtl...
剛進公司，我就發現一個bug，在win98下，第一次可以啟動，第二次不行，第三次可以，第四次不行... winMe，2k，xp都沒有問題，就是98有這毛病。PM說沒關係，客戶都是一開一天，沒人報這個問題，但我看著這樣的bug很心煩，嘗試幾次，都不明所以。
三年過去了，我要離開公司了。其間，只有我時不時的想要解決這個bug，但都沒有結果。在公司的最後幾天，我已沒什麼事情，就調試起這個bug。我把整個操作系統做了快照，比較第一次和第二次運行時系統的變化。終於發現了原因，
一個windows api在98下用預設參數調用的時候，會生成臨時文件，恰好覆蓋我們配置文件的緩存，被覆蓋的緩存會導致第二次無法啟動，所以那個api不會再被叫到，這樣第三次又可以啟動了。只要不用預設參數，bug就fix了。
一個三年的bug，原來如此。當時的感覺是，天亮了！這三年值了！
不知道那個fix最終有沒有release，因為那時候已經快要停止支持98了。「密集恐懼症」者慎入！！！
-------------------------------------------------------------------------------------------------------
群里程序員同事分享的，完美再現程序員發現bug的心情，笑一笑十年少~
8張圖讓你了解發現bug的體驗O(∩_∩)O哈哈~
救命呀！！！
1.寫完程序（運行）
2.出現bug（怎麼可能（‵□′），明明這麼完美(???_??) ）
3.仔細看看（好吧，沒事，我離成功就差一個bug了(≧▽≦)）
4.改好運行
5.出現一群bug
6. ……（媽蛋(╥ω╥`) ）。
這要看誰告訴我bug的。
QA和我反應bug，第一反應就是「卧槽，這貨會操作嗎」；第二反應是「我電腦上都沒問題的啊」；第三反應是心虛「他妹的怎麼又來bug了，還讓不讓人活了」；第四反應是認命「好吧，你給我重現一下，我看看是什麼問題」；之後進入bug修正流程。最後是「MD，遲早亂刀砍死尼們」。。。
自己發現bug，先慶幸下QA們沒發現，默默修正之，再讚美下自己鄙視下QA。
有bug運行幾天才能重現一次，這種才是最令人抓狂的，不知道怎麼重現問題，簡直想死的心都有了。別人寫的BUG讓自己發現：好比別人的娃拉泡屎讓你抽紙拎鏟子，各種不情願和被逼迫。
自己寫的BUG讓別人發現：好比自己的娃被別人拽著胳膊帶到你面前，雖然有點不好意思，但是該收拾還是得收拾。
自己寫的BUG讓自己發現：好比自己的娃小偷小摸讓自己看見，能不聲張就不聲張。
自己寫的BUG讓客戶發現：好比自己的娃當眾拉 泡屎，能說孩子生病了就說孩子各種病 。
兩小時前剛修復了一個出現了四個月的多線程bug，每三五個星期會出現一次，這次終於被log住要點了。
改了三五行代碼就行，感覺自己的職業發展又穩固了一點，開口要年終獎時更有信心了。
小bug喝口水醒醒神，大bug抽支煙冷靜冷靜，超級bug一甩手明天再來。
只能說，每次面對bug的時候，我還是很羞愧的。
居然有這麼多兄弟點贊。認真寫幾句吧。
我面對自己的bug時，真的還是挺羞愧的，前不久一個兄弟告訴我的定時器處理類，有個很隱蔽的bug，還是不好意思了半天。我覺得這個bug如果是自己的，低頭認錯。絕對是對的，別為了一個bug把各個環節的人都找來了，沒意思。
解決其他人的bug是最煩惱的，看懂人家的代碼……，不容易呀。
還有一些bug，實在是一些奇特的需求和設計導致的。年輕是我在代碼注釋里隱晦的問候過他們很多次。
如果樓主問的是如何調試？
推薦一本書《Windows 程序調試》《Debugging Windows Programs》
裡面寫了一些關於調試心理學的東東。
錯誤調試的五部曲
伊麗莎白-庫伯勒-羅斯（1969著作「On Death and Dying」 ，大陸譯本叫《論死亡和瀕臨死亡》）觀察到病人面對死亡等災難時有著不同的反應，她把這些反應劃分為五個階段，這五個階段也就是錯誤調試的態度。
§否認（Denial）：這是一個Bug嗎？是我的嗎？
§憤怒（Anger）：測試人員為什麼挑刺。
§討價還價（Bargaining ）：是否在下個版本修正。
§沮喪（Depression ）：我不合適做程序員
§容忍（Acceptance ）：下個版本也許就消失了
只有勇於面對錯誤才能成為一個有尊嚴程序員而生存下去。
正確調試的五部曲
§確定錯誤的存在:通過調試代碼，單元測試，聯合調試，集成測試確認問題。
§收集錯誤信息：收集問題的原因，不要放過任何細節。
§分析錯誤原因：通過分析收集的錯誤信息，定位問題的原因。
§消除錯誤：通過修正代碼解決問題
§驗證相關的修改：驗證修改是否解決了問題
其實調試，最後，還是一個態度問題
v不要責怪測試員為你發現了錯誤。
v錯誤幾乎不會「消失」，
v馬上修改錯誤，不要推遲到最後
v盡量編寫和測試小塊代碼。
v修改錯誤要治本，不要治表。
v養成好的編碼習慣和調試習慣，建立自己的原則，並且堅持。
v決不允許同樣錯誤出現兩次
v以上建議都來自《編程精粹》最後一章，請大家自己仔細閱讀。
哈哈，作為一個偏軟的IT相關研究僧，表示，這是狀態好的時候：
（圖片來自網路，下同）
狀態差的時候，是這樣的：
或者這樣：
「當遇到bug 我一般會先自省 仔細查看是不是自己的bug 當確定是 再考慮如何把這個鍋丟出去」
這個要看誰寫的bug
別人的bug被發現，卧槽，傻逼啊，為什麼這麼寫，bula bula
我寫的bug，還好沒有讓別人發現，不然又要被罵成傻逼，其實也不是我要這麼寫，一定有原因的，要不就沒有考慮到那麼奇葩的場景，我馬上改！
沒錯，我就是這樣一個市井小民，一個慫貨，對別人的錯誤嚴懲不貸，對自己的錯誤....知錯就改！
這個金貼的也是成功！
解決不了時
解決後
然後
Bug永遠都會有新的，但是發現一個bug的時候，自己會想原來這個地方還沒想到，解決了之後，感覺產品又更完美了一點，更踏實了一點。
程序員是一份很有挑戰的工作，沒有人能做到完美，寫錯代碼也是常有的事。
那麼，當程序員發現自己辛辛苦苦碼的代碼出錯的時候，會有哪些反應呢？
1、「是刪除它，還是修改它呢？好糾結 T T」
如果選擇刪除，那麼就需要重新開始寫，但是如果選擇修改，那麼就需要大量返工才能糾正錯誤。有時候就會陷入選擇刪除，還是修改的思想鬥爭，這折磨著一批又一批的程序員。
2、「我應該檢查Github來啟動框架。」
大多數開發商都知道GitHub，GitHub是一個面向開源及私有軟體項目的託管平台，每天在GitHub上都有新的海量的開源項目。程序員可以用GitHub從另外一個項目進行分支，或者重新生產自己的代碼。GitHub是一個很棒的平台，已經成為了管理軟體開發以及發現已有代碼的首選。
3、「為什麼這個腳本需要這麼多的庫？」
當使用更複雜的語言，如java和Objective-C時，庫文件的數量會急劇增加。建設一個好的框架，需要打好底子，但是這就意味著需要更多的附加文件，甚至一些JavaScript插件也需要大量的附加文件。但是這種雜亂無章的東西會令人感到煩躁。
4、「網上一定有解決的辦法。」
很多程序員在碰到棘手問題時的第一反應是：上網查找解決辦法。他們會發布論壇帖子來討論他們的問題，最終得到解決辦法。Google可以根據你搜索的關鍵詞，從大量信息中搜索出有用的內容。但是網路不是萬能的，很多時候，網上並沒有太多與你碰到的問題相關的信息。
5、「是否有可以使用的插件？」
插件是一個偉大的東西，能用於任何程序和網站擴大用戶界面。此外，還可以為開發人員提供一些」定製服務」。另外，如果已有的插件中沒有一個可用的，為什麼不自己開發一個？
6、「網上能找到辦法，但是我不想使用IE瀏覽器。」
IE瀏覽器現在已經是IE10版了，但是Web開發人員還是害怕用IE瀏覽器進行調試，但是好在微軟在不斷優化IE瀏覽器，使得開發變得越來越方便。
7、「對個邏輯語句似乎不太合乎邏輯。」
if/else 、for 、while 、do... 當代碼中有很多邏輯語言時，如果想要搞清楚其中的邏輯，程序員完全可以把自己繞暈。所以，為了未來能更好理清思路，需要經常回過頭去更新自己的邏輯表達。
8、「我花了30分鐘寫程序，卻花了兩個小時使它跑起來。」
很多時候寫一個程序只需要花很短的時間，但是如果在跑程序的時候發現程序跑不起來，那麼可能就需要花費很多精力了。定位到錯誤，再解決錯誤，這個過程就是一個很麻煩的過程。
9、「在看了別人的博客文章之後，我才意識到自己從一開始就已經錯了」
很多時候，程序員喜歡先用我自己的編程思想來思考問題。但當事情不按計划進行時，程序員就會去尋求博客或他人的幫助，有時候就會發現自己從一開始就已經錯了！磨刀不誤砍柴工，先做一點研究，最後肯定能節省時間。
10、「 Stack Overflow可能能幫到我。」
很多人會通過Stack Overflow來解決難題。Stack Overflow上有很多熱心的大牛，他們都願意幫助你解決難題。一般只要你敢問、願意問，都能得到一些解決辦法，尤其是問關於軟體編程和前端/後端Web開發的問題，絕對能得到別的平台無法得到的最棒的解決方案。
11、「所有的麻煩，都源於缺少了一個表示結束的右括弧。」
調試是一個不斷前進的過程，後退一步，前進兩步，最後完成項目。有時候會發現盯著代碼數小時所尋找的錯誤原因，只是缺少了一個右括弧，內心會有一萬頭草泥馬奔過。所有的時間都浪費了，只是因為一個小的語法錯誤。這時候會特別想拍死自己。
12、「我需要喝杯咖啡休息一下！」
在電腦前工作了很久還是找不到錯誤，選擇喝杯咖啡休息一下，或許能產生不一樣的靈感。大多數的健康指南都建議每工作30-60分鐘就休息一下。但這都取決於你的內心，如果在工作過程中停下來休息會使你生氣，那你還是不要停下來休息了。
13、「我應該擱置這個項目，以後再處理。」
如果你不想休息，你也可以把項目先擱置，可以去做別的工作，這比起苦惱地盯著電腦看上一天好太多了。暫時解決不了，不如開始新工作，這將是對時間和資源更好的分配方法。
14、「我不知道古典音樂是否會刺激我的編程能力。」
有一種觀點認為，古典音樂可以催生靈感。古典音樂的複雜音符和複雜的音樂理論，在世界各地的人類文化中都佔有一席之地。在編程的同時聽古典音樂，可能會使調試過程更順利，但是這個得因人而異，有些人並不喜歡古典音樂，讓他聽古典音樂可能更是一種折磨。
15、「也許現在是檢驗巴爾默峰值理論的好時機。」
很多人都知道巴爾默峰值理論，即程序員在攝入一定量的酒精後，編碼能力可以達到峰值。很多人會把這個理論當成是史蒂夫·鮑爾默這個酒鬼的胡扯。至於這一理論是否有效，實踐一下就明白了。
16、「是有人篡改了我的源代碼嗎？」
這聽起來有點像被害妄想症，但當你毫無頭緒時，你就會嚴重質疑自己，甚至會想通過捏造一個不存在的人來轉移自己的情緒。這個世界上總有一些你永遠記不住的東西—即使是你上周剛剛看過的項目，在真正需要被回憶起來的時候也會變得毫無印象！
17、「我完全理不清這意味著什麼。」
最壞的情況就是當你查看源代碼時，完全不知道該怎麼做。你在自己的項目和別人的項目中都發現過同樣的問題，但是你就是搞不懂為什麼。這時候你必須決定是否值得花更多的時間尋找一個替代方案，或是解剖腳本以了解它是如何工作的。
18、「我需要Google一下錯誤信息。」
對於PHP工程師來說，Google是調試問題時最好的朋友，當然，Google對於C、C++、java、python和其他主要語言來說，也是一樣重要的。了解錯誤信息是有用的，至少可以知道這個錯誤代碼代表了什麼意思。
19、「今天就到這兒了…但我真的想弄明白！」
當你想要放棄，但是又不願意放棄的時候，這種感覺真的很絕望啊。你想繼續推進，嘗試調試出新的解決方案，但又覺得自己能力有限可能找不出解決方案，但又感覺到放棄不是正確的選擇。這又是一個尷尬的境界，對於有選擇困難症的程序員來說就是一個大災難。
20、「哦，為什麼我沒有寫註解？」
當涉及到基本的HTML/CSS/JS時，並不總是需要寫註解。但遇到更複雜的腳本和程序時，則需要寫一些的註解。當你想在幾個月，甚至幾年後回顧的時候，這些註解能幫助你。有時不寫註解，當錯誤出現時，就必須調試整個腳本才能找出解決方案。但如果有一些有用的註解，情況就會好很多。
21、「20分鐘前它還是好的...」
構建程序最令人沮喪的部分可能是：它會毫無徵兆地從正常工作變到突然卡殼。有時還會出現只是更新了一個小的代碼，卻導致整個程序崩潰、完全停止工作的情況。你需要把它恢復到最新的工作副本，重新從那裡開始前進。
22、「我忘了一個分號，結果整個程序崩潰了。」
幾乎每一種編程語言都需要一個終止符號。你可能覺得一個終止分號並不重要，加不加都無所謂，但是語言分析程序並不理解這一點。現在你又要花很多時間來排除這個錯誤了，雖然對於整個程序來說只是缺少了一個分號，但是對於你來說卻是費力不討好的。
23、「我想知道讓別人來幫我修補錯誤，要花多少錢？」
僱傭另一個開發者來幫忙，這樣壓倒性的想法是非常誘人的，但顯然在經濟上幾乎不可行。再者，如果是自己動手修補錯誤，就能從這些錯誤中學到好多東西，最終理解編程概念。所以，還是把錢留著，多學點東西吧。
24、「我需要看看黑客新聞來提高我的生產力。」
如果想要了解軟體和創業，程序員會首選黑客新聞網站。那裡有許多關於自由職業、時間管理，軟體開發、創業和集資這樣的內容。雖然看黑客新聞可以自我激勵、自我教育，但也會耗盡很多的時間，如果每隔幾個小時快速瀏覽一下就不會那麼糟糕了。
25、「這個API怎麼沒有文件？！」
使用插件或框架時最令人沮喪的部分是沒有好的文件，你必須自己深入查看源代碼。有些開發人員會花時間專門設計一個可用文檔頁的項目。所有參數和選項都會被注釋，甚至可能在一些示例代碼片段中被使用。但是很多人不會那麼做，最後碰到問題了就會淚奔了。
26、「我真希望我已經保存了那個資料庫的備份副本…」
對數據進行備份是很必要的，可以確保在發生一些變化時能及時返回，尤其是對那些實時變化的內容。要時刻記住保存網站文件和資料庫到本地，以防意外的發生！這可能是一個煩人的任務，但這比重建一個損壞的SQL資料庫好太多了。
27、「有沒有最快的解決辦法，能使它正常工作？」
每個程序員都希望能找到一個起效最快最快、效果最好的的解決方案，能夠百分百地實現工作。然後，這會是很困難的。
28、「我打賭更新我的軟體會解決這個問題。」
有些時候只需更新PHP / Ruby / Python / SQL版本，即可解決調試問題。但是，除非你的版本完全過時了，本地更新對於幫助修復源代碼中的bug作用會很小。不過，這個辦法還是值得一試！
29、「我應該更系統得學習Git…恩，下周我一定會的。」
Git在程序員中非常流行，為開發者提供更多的便利。對於初學者來說，Git的學習有一個陡峭的入門曲線，一旦你了解了基本的命令，Git便是小菜一碟。而且，它能使調試與版本控制更加清晰。如果能系統地學一下Git，會使工作變得更高效，然而...
30、「廢了它，我從頭開始。」
經過幾個小時的嘗試解決後，有些容易衝動的程序員就會Delete it，從頭開始。這意味著前面幾個小時的辛苦工作都將付之東流，對於這種，你開心就好，從頭開始沒準更有用呢~
歡迎關注我的微信公眾號：九章演算法（ninechapter），幫助你了解IT技術前沿，通過面試、拿到offer、找到好工作！
如果那是全自己寫的代碼，我基本是這樣的：
被分配bug：「酒且斟下，某去去就來。」
提交以後：「酒尚溫否？」
千萬不能讓QA那幫死丫頭知道！
ps 我就是那幫死丫頭…如果是自己已經參與一段時間的項目，會思考為啥會有bug！前期思路不對？case沒考慮完整？測試不夠細緻？為什麼！然後改改改。
如果是別人寫的項目，發現重大bug會默默喊一句坑爹！然後自我陶醉一會兒，再思考要不要改。如果原先的項目邏輯混亂，就直接申請一兩個月重構…… 如果原本模塊很簡潔，果斷改改改。如果頭兒不讓改（種種原因），那就寫個注釋以後改。
推薦閱讀：
※有虎牙是一種怎樣的體驗？
※如何評價 vczh？
※如何評價薛之謙 9 月 21 日對李雨桐的再次回應，並曬出轉賬記錄？
※語音識別的技術原理是什麼？
※有哪些看似很帥，其實很傻的行為？