程式設計師在普通人的印象裡是一份嚴(ku)謹(bi)的職業，也是一個被搞怪吐槽樂此不疲的職業，程式設計師們面對複雜的程式碼敲打電腦時連眉頭都不會皺一下，但是有一個詞卻是他們痛苦的根源，它就是Bug。

（小編推薦一個學C/C++的學習群892643663，入群即送C/C++全套學習資料，滿滿的乾貨！）

程式設計師調 Bug 的感覺

就是這樣的一波未平，一波又起

千萬不要和程式設計師直接說有 Bug

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

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

1.“我不知道是要刪除還是要重寫它”

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

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

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.“算了，我還是從頭再開始吧。”

有時候，在你絞盡腦汁花費數個小時之後，可能要做的只是將你的工作檔案移動到歸檔目錄（或刪除它們），再從頭開始就可以了。但是，考慮到先前已經耗費的時間，你很難下定這個決心。

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

的正確道路。

（小編推薦一個學C/C++的學習群892643663，入群即送C/C++全套學習資料，滿滿的乾貨！）

為什麼程式設計師發現不了自己的 Bug？

作為開發就和我們成人一樣看到問題總是以自己的世界觀來理解，導致理所當然的就這樣就對了，而真正的真相就被隱藏了。

當程式設計師面對 Bug 的時候，如何機智甩鍋？

當你面對 Bug 時，切勿慌張，以下措施教你輕鬆應對 Bug 帶來的困擾。

1.打死不承認，這程式碼不是我寫的，將鍋甩出去。

2.睜眼說瞎話，在我電腦上是正常的呀，超級無辜。賺取同情分

3.對方使用了錯誤的開啟方式。

一定是對方的開啟方式不對，重新開啟試試，我神馬都不知道

4.痛斥產品經理一頓，自己偷偷改好，氣勢不能弱，立場要堅定，迅速進入角色，完全沒有 Bug 這回事，我就是王道。

以上模式可任意切換使用，但最終都逃不了，自己背地裡偷偷，改 Bug 的宿命。

小夥伴們有什麼想說的

歡迎在下方評論區留言哦！

（小編推薦一個學C/C++的學習群892643663，入群即送C/C++全套學習資料，滿滿的乾貨！）