程式設計師遇到Bug時的30個反應

本文由碼農網 – 小峰原創翻譯，轉載請看清文末的轉載要求，歡迎參與我們的付費投稿計劃！

開發應用程式是一個非常有壓力的工作。沒有人是完美的，因此在這個行業中，程式碼中出現bug是相當普遍的現象。面對bug，一些程式設計師會生氣，會沮喪，會心煩意亂，甚至會灰心喪氣，而另一些程式設計師會依然保持冷靜沉著。因此，如何處理修復bug的過程也值得我們細細琢磨。

我想分享一些程式設計師修復他們的原始碼時所經歷的想法。這是事情變得緊張時所觸發的輕鬆幽默。通常說來，應用程式終將可以工作，然後你也可以進入到下一個偉大的任務。

我相信很多web開發人員和軟體工程師經歷過這些艱辛，然後在事後一笑而過。

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

有時候，在你絞盡腦汁花費數個小時之後，可能要做的只是將你的工作檔案移動到歸檔目錄（或刪除它們），再從頭開始就可以了。但是，考慮到先前已經耗費的時間，你很難下定這個決心。但是，當我一籌莫展時，我往往會選擇從頭開始，因為這樣才有可能找到完成專案的正確道路。