世界之謎：為什么程序員總是發現不了自己的Bug？
程序員在普通人的印象里是一份嚴(ku)謹(bi)的職業，也是一個被搞怪吐槽樂此不疲的職業，程序員們面對復雜的代碼敲打電腦時連眉頭都不會皺一下，但是有一個詞卻是他們痛苦的根源，它就是Bug。
測試人員、開發人員、管理人員對 Bug 的不同反應
當程序員找 Bug 的時候
程序員調 Bug 的感覺，就是這樣的一波未平，一波又起
開發人員在演示中如何隱藏 Bug
叫新手程序員幫忙改 Bug
牛 X 程序員和 Bug 之間的 PK
千萬不要和程序員直接說有 Bug
程序員遇到 Bug 時的 30 個反應
開發應用程序是一個非常有壓力的工作。沒有人是完美的，因此在這個行業中，代碼中出現 Bug 是相當普遍的現象。
面對 Bug，一些程序員會生氣，會沮喪，會心煩意亂，甚至會灰心喪氣，而另一些程序員會依然保持冷靜沉著。因此，如何處理修復 Bug 的過程也值得我們細細琢磨。
我想分享一些程序員修復他們的源代碼時所經歷的想法。我相信很多開發人員和軟件工程師經歷過這些艱辛，然后在事后一笑而過。以下你經歷過哪些？
1.“我不知道是要刪除還是要重寫它”
回顧從前老的源代碼，會有一種想要返工寫成較大塊集群的沖動和誘惑。丑陋的邏輯語句，還有冗長的語法，導致代碼非常難以閱讀！
但話又說回來，如果代碼沒有壞掉的話，那就不要去修復它。這種洶涌澎拜的斗爭是我經常要面對的，而且顯然會困擾許多軟件開發人員。
2.“對于起始框架我應該查看 Github”
我想大多數開發人員都知道 Github，上面每天都有數量驚人的開源項目發布。
任何語言的程序員都可以通過互聯網借鑒現有項目，加入維基討論，或者創建自己的代碼倉庫。它是各種項目所需插件和模板的超棒資源。
3.“為什么這個腳本需要這么多庫？”
尤其是一些比較大眾化的語言，如 Java 和 Objective-C，庫的數量可能變得異常兇猛。當構建一個需要大量基礎的框架時，所需的庫的數量就變得顯而易見得多。
即使是一些適用于 JavaScript 的插件，也會額外需要無數的文件。有時，這會讓人覺得煩雜惱人——但至少是有用的！
4.“在互聯網的某個地方一定已經有了解決方案。”
我面對棘手問題的第一反應是上網查。程序員會將他們遇到的問題通過帖子發布到論壇上，然后這個問題最終得到解決并歸檔。
谷歌搜索問題關鍵字的好幫手，可以指點你往正確的討論方向走。不幸的是，有的時候卻是因為手頭沒有特定問題的太多信息而找不著北。
5.“有沒有這個功能的插件？”
為什么要重新發明輪子？插件是擴大任何程序或網站用戶界面的偉大資源。此外，它們還為開發人員提供了一些自定義和獨特的選項。萬一真的沒有可用插件的話，為什么不自己構建一個呢？
6.“雖然網站可以工作，但我害怕 IE 瀏覽器。”
在 Internet Explorer 中渲染網頁的歷史充滿了艱辛考驗，是我們有目共睹或親身體驗過的。
從 5.5 版本升級到 IE9、IE10，總是需要爭取到更高級瀏覽器的支持。Web 開發人員可能會害怕調試網頁，因為在 IE6 中打開頁面是一個渲染噩夢。值得慶幸的是，這樣的日子正在慢慢成為過去。
7.“對于邏輯表達式而言，這似乎并不怎么合乎邏輯。”
對于 if / else 循環，for 循環，while 循環，do 循環等等，都有邏輯表達式。當瀏覽示例代碼時，我試圖指出我的邏輯是如何工作的。
NOT 運算符和比較標記的數量又是如此之多。我經?；剡^頭去更新我自己的邏輯以便于更好地適合未來的做法。
8.“我用 30 分鐘寫函數，花 2 小時讓它工作。”
這難道不像我們自己的編程故事嗎？你正興致勃勃地在構建著什么，但是突然之間，函數輸出了一個致命的錯誤。
所以，現在你必須回過頭去刪除一些代碼塊，以找出錯誤發生的行號。當你終于找到罪魁禍首，并解決它時，雖然有種精疲力竭的感覺，但也滿心安慰。
9.“在閱讀多篇博客文章之后，我意識到，我之前全都是錯的。”
我常常會一開始就根據自己的編程思想，一頭扎進去研究，但是這可能會導致麻煩，如果事情不像原先設想地那樣順利的話。
已經有很多次在我啟動一個項目之后，陷入了困境，然后只好尋求博客和其他論文的支持。
最后我發現我的整個方法實際上是錯誤的，而且從頭來過更容易！如果我開始的時候能先做一番研究的話，從長遠來說，反而節省時間。
10.“Stack Overflow 上和善的人或許愿意幫助我。”
我已經數不清有多少次我通過 Stack Overflow 解決了難題。社區里都是和善和聰明的人，他們非常愿意提供幫助，如果你邁出第一步的話。
在所有的在線論壇中，Stack Overflow 絕對是對軟件編程以及前端 / 后端 web 開發支持最廣泛的網絡。
11.“花費大力氣才找出問題的原因是缺少了右括號。”
調試是你必須要采取的步驟，進兩步，退一步。盯著代碼數個小時，以為函數名或變量作用域中有哪里搞錯了，最后才發現是遺漏了一個括號，這滋味，酸爽得不要不要的。所有這些時間都因為一個小小的語法錯誤而浪費。
12.“喝杯咖啡，休息一下！”
有時候，你只是需要站起來，遠離顯示器。將鼠標懸停在鍵盤數個小時，反而有助于打破常規。大多數健康指導都會建議我們每隔 30-60 分鐘休息一會。
但是這一切都取決于你的需要，如果你覺得在程序中間休息更令人懊惱的話，那就不要中斷。
13.“我應該把這個項目束之高閣，以后再來處理它。”
休息的另一個選擇是離開你的項目，而不僅僅是遠離你的電腦。如果還有其他工作需要做，那么不妨去做其他工作。
相對于已經花費了 5 個小時來解決問題依然不得入門而言的話，這將能更好地分配時間和資源。
14.“我很懷疑古典音樂能否激發我的編程能力。”
有一種說法是，古典音樂可以在生命的早期階段促進植物生長。我個人非常喜歡在寫復雜筆記時聆聽古典音樂。爵士樂、鋼琴、大樂團，優雅的音樂在全世界的人類文化中都有一席之地。
那么，在編程的同時傾聽智慧的音樂真的能夠讓你更智慧地調試嗎？可能不會，不過希望它不會讓你變得更笨拙。
15.“喝點酒吧，也許現在是檢驗鮑爾默峰值理論的好時機。”
很多讀者都聽說過鮑爾默的峰值理論，根據一個特殊 XKCD 漫畫而得出。簡單地說，這個理論認為程序員的編碼能力在喝了一定量的酒之后，會達到一個峰值。
作者名叫史蒂夫 · 鮑爾默，他的行為古怪，就像是一個醉漢，這有一定的諷刺意味，因為鮑爾默在微軟從來就不是一名真正的程序員。也許我們需要等待別人來實踐證明這個理論吧。
16.“是不是有人動過了我的源代碼？”
這聽起來有點妄想和偏執，但有時你會不由自主地懷疑，是不是有人在你補覺的時候，寫過這個東西了。
回顧過去幾周或幾個月做的項目會讓你的心不斷地往下沉。有時候你會發現一些你已經不記得添加的東西——甚至這個項目你最近一周才剛剛瀏覽過！我為代碼而瘋狂，但你永遠不會知道…
17.“我不知道這意味著什么。”
你能遇到的最壞情況是，你對你正在瀏覽的源代碼完全不知道該怎么做?？赡苁悄阕约旱捻椖?，也可能是別人的項目，但問題的根源是相同的。
現在，你必須決定是否值得花更多的時間去搜索替代方案，或仔細檢查腳本以了解它是如何工作的。
18.“我需要 Google 錯誤信息。”
在 PHP 中工作了多年之后，我不得不說，Google 是我調試問題時最好的朋友。使用 Objective-C、C++、Java、Python 和其他主要語言，也是如此。
錯誤信息非常有幫助，但是除非你記得不同的代碼意味著什么，否則它讀起來更像是翻譯過的計算機語言。值得慶幸的是，有很多在線支持可以幫助我們確定這些錯誤信息的真正含義。
19.“我應該停下來，收工…… 但我真的很想解決它！”
我們都有過極度灰心喪氣，想要放棄的感受，但總感覺半途而廢不是正確的選擇。于是，你繼續埋首鉆研，并嘗試新的解決方案來調試。
但是，如果這還是意味著另一個小時的浪費呢？對于這樣的情況我并不陌生，令人非常令人沮喪。
20.“哦，天哪，我以前為什么不寫點注釋呢？”
當涉及到比較基礎的前端 HTML / CSS / JS 時，我們沒有必要寫注釋。但更復雜的腳本和程序卻需要一定形式的條理組織，當你在幾個月后，甚至若干年之后需要再回過頭來看的話。
有時你會忘記注釋函數及其參數、輸出格式，和其他的必要數據。這在一段時間之后無疑會導致混亂。而且，當 Bug 開始出現時，你必須調試整個腳本來尋找解決方案。因此，要是有一些有幫助的注釋就會讓你獲益良多。
21.“20 分鐘前它還可以工作的……”
在構建程序時，可能最令人沮喪的部分就是，它從能工作到不能工作——而你沒有更新代碼的任何部分！我發誓這是真的，而且這是沒有任何意義的事情——也許是其他程序正在運行緩存版本？
有很多次你更新了一丁點代碼，卻導致了整個程序崩潰出錯，完全停止了工作。恢復到最近可工作的復制文件，然后從那里開始一步步前進。
22.“只是忘記了一個分號，然而整個程序卻因此而轟然倒下。”
幾乎所有我使用的編程語言都需要結束符。雖然不是所有的語言都有，但在 C/C++ 中是很常見的。
忘記添加結束符，不過是一個很顯然的錯誤！但是解析器不知道這一點，它會拋出一個致命錯誤。
于是，你不得不額外花 20 分鐘去搜索技術故障，而原本只需要用 1 秒鐘補上那個缺少的分號即可。嗯，這就是調試軟件的樂趣。
23.“我不知道讓別人來修復我的代碼，得花多少錢？”
聘請另一個開發人員的點子是挺誘人的，但從財政上看顯然沒有那么可行。而且如果你不親身體驗的話，又怎么能從這些錯誤中學到東西呢？
當你在經歷多次失敗之后，終于理解了某個編程概念的時候，那感覺真是棒極了。盡管如此，我的腦海里依然時不時地有一種 “讓別人來修復代碼” 的沖動。
24.“快速瀏覽 Hackers News 可以提高我的工作效率。”
很多程序員最喜歡閱讀的，有關于軟件和創業公司等社會新聞的選擇是 Hackers News 頭版。它有很多關于自由職業、時間管理、軟件開發、以及創業發布和融資的大量信息。
雖然 HN 可以通過自我教育讓你感覺自己變得更有效率了，但同時它也會浪費你的時間。每隔幾小時去快速瀏覽下 Hackers News 也不是那么糟糕。
25.“這個 API 怎么沒有文檔？！”
在使用帶有壞文檔的插件或框架時，最令人沮喪的是，你必須靠自己去深入鉆研源代碼。我喜歡開發人員花時間去專門設計可用文檔頁面的項目。
所有的參數和選項都解釋得清清楚楚，甚至可能會被用在一些示例代碼片段中。但可悲的是，事實并非總是如此。所以最簡單的方法是遠離不良文檔，不自找麻煩。
26.“我真希望我保存了那個數據庫的備份副本……”
在編寫和調試代碼時，我不會想到要備份。然而，數據備份提供了允許我們回過頭去修改的踏腳石。這在實時的服務器環境中尤為有用，因為有什么變化會立即執行。
以防萬一，我們應該記得保存網站文件和數據庫的本地副本！雖然這會是一個惱人的任務，但其惱人程度遠遠比不上重建損壞的 SQL 數據庫。
27.“讓它正常工作的最快解決辦法是什么？”
在花費數個小時苦苦思考自定義的解決方案之后，很明顯你需要一種新的方法。在設計漂亮的界面之前，程序員率先想到的是讓功能正常工作。
確定最快、最準確的解決方案，并實施這個解決方案讓其工作才是 100％ 利用了時間，然后再轉移到漂亮美觀方面。
28.“我敢打賭更新我的軟件將解決這個問題。”
管理編程語言依賴和插件的團隊并不需要經常發布版本。有時，在你從計算機傳輸文件到實時服務器的時候，更新 PHP / Ruby / Python / SQL 版本可以解決調試問題。
本地更新很少能夠幫助修復源代碼中的 Bug，除非你的版本已經過時得無可救藥。所以，值得一試！
29.“我應該更有條理并且去學習 Git …… 下周就去研究它。”
開源版本控制包 Git 在程序員中非常受歡迎。相對于其他的競爭對手，它提供了更容易的學習曲線，并且被許多在線代碼倉庫，如 Github 上和 Bitbucket 使用。
開發人員很容易拖延去學習 Git 的行動，因為它對于初學者而言顯然是有難度的。但是一旦你知道了基本命令，那么 Git 就是小菜一碟。而且它還能使調試版本控制更加清晰。
30.“算了，我還是從頭再開始吧。”
有時候，在你絞盡腦汁花費數個小時之后，可能要做的只是將你的工作文件移動到歸檔目錄（或刪除它們），再從頭開始就可以了。但是，考慮到先前已經耗費的時間，你很難下定這個決心。
當我一籌莫展時，我往往會選擇從頭開始，因為這樣才有可能找到完成項目的正確道路。
為什么程序員發現不了自己的 Bug？
最近在朋友圈流行了這樣的一個小學數學題，當然結果是“出乎意料”，看似簡單的結果，幾乎很少有人做對，而分析下來的原因無非是慣性思維下的粗心導致的完全錯誤，今天小編就帶大家一起分析下思考過程。
看圖可知，貓=X 貓頭=Y 貓爪=Z，既：
- 3X=30
- X+Y+Y=20
- Y+Z+Z=9
所以得出 X=10 Y=5 Z=2，故結果：Y+Z+X=5+2+10=17。
一般大多數的第一結果可能都是這樣！等等，注意最后一個應該是Y+Z×X=？
心中一百只草泥馬奔過，再算一遍，Y+Z*X=5+2*10=25。
對不起還是錯的，因為貓爪從 2 只。
變成了 1 只。
所以應該是Y+Z/2*X=?心中一千只草泥馬奔過，再算一次：Y+Z/2*X=5+2/2*10=15。
對不起還是錯的，因為最后一只貓少一個爪子，所以應該是：Y+Z/2*(X-Z/2)=?
心中一萬只草泥馬奔過，再算一次：Y+Z/2*(X-Z/2)=5+2/2*(10-2/2)=14。
其實大家會發現這個題目非常的“坑爹”，不就是故意折騰人么，但是在很多系統中，開發看到測試提出的 Bug 也是這樣的感覺。
作為開發就和我們成人一樣看到問題總是以自己的世界觀來理解，導致理所當然的就這樣就對了，而真正的真相就被隱藏了。
而兒童一般能夠做對的原因是，老師有引導性的提示細心的重要性并且長期踩雷。這也是測試人員和開發人員的區別之一，現在知道為啥測試不是誰都能做的工作了吧，開發也為啥找不到 Bug 了吧。
當程序員面對 Bug 的時候，如何機智甩鍋？
當你面對 Bug 時，切勿慌張，以下措施教你輕松應對 Bug 帶來的困擾。
1.打死不承認，這代碼不是我寫的，將鍋甩出去。
2.睜眼說瞎話，在我電腦上是正常的呀，超級無辜。
賺取同情分
3.對方使用了錯誤的打開方式。
一定是對方的打開方式不對，重新打開試試，我神馬都不知道
4.痛斥產品經理一頓，自己偷偷改好，氣勢不能弱，立場要堅定，迅速進入角色，完全沒有 Bug 這回事，我就是王道
以上模式可任意切換使用，但最終都逃不了，自己背地里偷偷，改 Bug 的宿命。
