這個要分情況、分人：

1、線上bug，緊急工單：操，真他媽倒黴，又休息不成了；

2、測試bug，不靠譜的測試人員，會說：傻逼又點錯了；靠譜的測試人員，會說：哎呦，我看看；

3、產品提的bug：操，你個傻逼又改需求；

4、運維提的bug：操，你個傻逼瞎改配置了吧；

5、自己提的bug：操，不提了，偷偷改了上線；

6、老闆提的bug：老闆，不懂就別裝懂拉：）

哈哈哈哈，這個就比較魔性了，我是覺得心裡藍受的一批，如果是自己以前有處理過類似的經驗還好，碰到一個問題不知道出在哪的bug，這個十分的藍受，，

開發應用程式是一個非常有壓力的工作。沒有人是完美的，因此在這個行業中，程式碼中出現 Bug 是相當普遍的現象。

面對 Bug，一些程式設計師會生氣，會沮喪，會心煩意亂，甚至會灰心喪氣，而另一些程式設計師會依然保持冷靜沉著。因此，如何處理修復 Bug 的過程也值得我們細細琢磨。

我想分享一些程式設計師修復他們的原始碼時所經歷的想法。我相信很多開發人員和軟體工程師經歷過這些艱辛，然後在事後一笑而過。以下你經歷過哪些？

回顧從前老的原始碼，會有一種想要返工寫成較大塊叢集的衝動和誘惑。醜陋的邏輯語句，還有冗長的語法，導致程式碼非常難以閱讀！

但話又說回來，如果程式碼沒有壞掉的話，那就不要去修復它。這種洶湧澎拜的鬥爭是我經常要面對的，而且顯然會困擾許多軟體開發人員。

2.“為什麼這個指令碼需要這麼多庫？”

尤其是一些比較大眾化的語言，如 Java 和 Objective-C，庫的數量可能變得異常兇猛。當構建一個需要大量基礎的框架時，所需的庫的數量就變得顯而易見得多。

即使是一些適用於 JavaScript 的外掛，也會額外需要無數的檔案。有時，這會讓人覺得煩雜惱人——但至少是有用的！

3.“有沒有這個功能的外掛？”

為什麼要重新發明輪子？外掛是擴大任何程式或網站使用者介面的偉大資源。此外，它們還為開發人員提供了一些自定義和獨特的選項。萬一真的沒有可用外掛的話，為什麼不自己構建一個呢？

4.“雖然網站可以工作，但我害怕 IE 瀏覽器。”

在 Internet Explorer 中渲染網頁的歷史充滿了艱辛考驗，是我們有目共睹或親身體驗過的。

從 5.5 版本升級到 IE9、IE10，總是需要爭取到更高階瀏覽器的支援。Web 開發人員可能會害怕除錯網頁，因為在 IE6 中開啟頁面是一個渲染噩夢。值得慶幸的是，這樣的日子正在慢慢成為過去。

5.“對於邏輯表示式而言，這似乎並不怎麼合乎邏輯。”

對於 if / else 迴圈，for 迴圈，while 迴圈，do 迴圈等等，都有邏輯表示式。當瀏覽示例程式碼時，我試圖指出我的邏輯是如何工作的。

NOT 運算子和比較標記的數量又是如此之多。我經常回過頭去更新我自己的邏輯以便於更好地適合未來的做法。

6.“我用 30 分鐘寫函式，花 2 小時讓它工作。”

這難道不像我們自己的程式設計故事嗎？你正興致勃勃地在構建著什麼，但是突然之間，函式輸出了一個致命的錯誤。

7.“在閱讀多篇部落格文章之後，我意識到，我之前全都是錯的。”

我常常會一開始就根據自己的程式設計思想，一頭扎進去研究，但是這可能會導致麻煩，如果事情不像原先設想地那樣順利的話。

已經有很多次在我啟動一個專案之後，陷入了困境，然後只好尋求部落格和其他論文的支援。

最後我發現我的整個方法實際上是錯誤的，而且從頭來過更容易！如果我開始的時候能先做一番研究的話，從長遠來說，反而節省時間。

8.“花費大力氣才找出問題的原因是缺少了右括號。”

除錯是你必須要採取的步驟，進兩步，退一步。盯著程式碼數個小時，以為函式名或變數作用域中有哪裡搞錯了，最後才發現是遺漏了一個括號，這滋味，酸爽得不要不要的。所有這些時間都因為一個小小的語法錯誤而浪費。

9.“喝杯咖啡，休息一下！”

有時候，你只是需要站起來，遠離顯示器。將滑鼠懸停在鍵盤數個小時，反而有助於打破常規。大多數健康指導都會建議我們每隔 30-60 分鐘休息一會。

但是這一切都取決於你的需要，如果你覺得在程式中間休息更令人懊惱的話，那就不要中斷。

10.“我應該把這個專案束之高閣，以後再來處理它。”

休息的另一個選擇是離開你的專案，而不僅僅是遠離你的電腦。如果還有其他工作需要做，那麼不妨去做其他工作。

相對於已經花費了 5 個小時來解決問題依然不得入門而言的話，這將能更好地分配時間和資源。

11.“哦，天哪，我以前為什麼不寫點註釋呢？”

當涉及到比較基礎的前端 HTML / CSS / JS 時，我們沒有必要寫註釋。但更復雜的指令碼和程式卻需要一定形式的條理組織，當你在幾個月後，甚至若干年之後需要再回過頭來看的話。

有時你會忘記註釋函式及其引數、輸出格式，和其他的必要資料。這在一段時間之後無疑會導致混亂。而且，當 Bug 開始出現時，你必須除錯整個指令碼來尋找解決方案。因此，要是有一些有幫助的註釋就會讓你獲益良多。

12.“20 分鐘前它還可以工作的……”

在構建程式時，可能最令人沮喪的部分就是，它從能工作到不能工作——而你沒有更新程式碼的任何部分！我發誓這是真的，而且這是沒有任何意義的事情——也許是其他程式正在執行快取版本？

有很多次你更新了一丁點程式碼，卻導致了整個程式崩潰出錯，完全停止了工作。恢復到最近可工作的複製檔案，然後從那裡開始一步步前進。

13.“算了，我還是從頭再開始吧。”

當我一籌莫展時，我往往會選擇從頭開始，因為這樣才有可能找到完成專案的正確道路。

十年java老兵 學習過多個阿里開源原始碼，歷經多個大型網際網路產品，可以講：遇到bug是非常自然的事情

當bug影響到業務的時候還是會著急，牴觸倒還真沒有，需要我們分辨哪些是系統級，哪些是業務級，並分清輕重緩急，然後制定修復計劃，最後需要覆盤如何規避 ，提升系統的健壯性。