開發應用程式是一項壓力很大的工作，人無完人，工作中遇到bug是很正常的事，有些程式設計師會生氣，沮喪，鬱悶，甚至洩氣，也有一些程式設計師則會比較淡定。如何進行修復bug的過程，是值得我們好好推敲的。
我想分享一些有關程式設計師在努力修復bug時常說的話和冒出的想法。當氛圍變得緊張的時候，這些話就會顯得輕鬆幽默。最終，bug也會修復成功，你將會繼續下一個任務。
我相信許多web開發人員和軟體工程師在程式設計中都會遇到困難，而事後回想起來，還會覺得很好笑。
1、我不知道該刪掉還是重寫
迴歸曾經寫的原始碼，總有一種想要重新返工的衝動，邏輯性差，冗餘程式碼多，讓人難以理解。但是，如果功能沒出現問題，千萬不要去修改。這是我經常要面對的困擾，相信也困擾了其他不少的軟體開發者。
2、一開始架構時就該查Github
相信絕大多數開發人員都知道Github，它上面每天都會發布的一些神奇的開源專案。所有語言的程式設計師都會利用網路，為已存在的專案建立分支，新增專案wiki描述，或者建立自己的程式碼庫，這些都為各種各樣的專案的外掛和模板提供了很多豐富的資源。
3、為什麼這個指令碼要依賴這麼多庫
說到一些越來越被廣泛使用的計算機語言，像Java和Objective-C，庫檔案的數量也不斷增加。很明顯可以看出，構建一個框架就需要許多的基礎庫，甚至一些JavaScript的外掛也需要很多大量的附加檔案。有時候這些亂七八糟的東西會很讓人心煩，但是至少它能執行。
4、網上一定有解決辦法
遇到困難時，我的第一反應就是上網查資料，很多程式設計師會在論壇上釋出他們的問題，最終這些問題都會被解決並存檔。Google會很神奇地選擇一些跟你的問題相關的關鍵字，你就能夠輕而易舉地得到一些對你有幫助的討論資訊。不幸的是，有時候對於一些特定的問題，相關的資訊還不是很多。
5、有這個功能的外掛嗎
何必要多此一舉外掛是擴充套件任何程式或者網站使用者介面的很好的資源。另外它們還為開發者提供了一些定製以及獨特的選項。如果沒有可用的外掛，那你為什麼不自己建立一個呢？
6、對於網站專案，我好擔心坑爹的InternetExplorer
使用IE渲染網頁遇到的各種困難，我就不提了，從5。5版本到IE9-IE10，對於瀏覽器的支援問題的爭議就一直不斷。Web開發人員會很害怕網頁除錯，使用IE6進行渲染更是噩夢。，幸好那些日子已經慢慢成為歷史了。
7、有些邏輯語句，並不符合邏輯
有一些邏輯語句，像if/else迴圈，for迴圈，while迴圈，do迴圈…等等，還有很多。在回顧一些原始碼時，我總是盡力想弄明白我的邏輯是怎麼回事。我經常會回頭更新程式碼，讓邏輯更清晰。
8、我花30分鐘寫個函式，執行它卻要花2個小時
這不是十年前的一個有關程式設計的故事嗎？當一切都在按照你所所期待的順利進行著，突然某個函式輸出了一個致命的錯誤，所以你不得不回頭刪除程式碼塊，試圖定位出錯的程式碼行。儘管這會讓你筋疲力盡，但是一旦找到錯誤的原因，問題解決之後，你又會立馬感到渾身輕鬆。
9、讀了幾篇部落格後，我才意識到我之前所做的全是錯的
我總是喜歡根據自己的程式設計思想直入主題，但是如果事情沒有按照我原本的計劃進行時，會導致很多麻煩。有很多次，我在做專案時，途中都遇到了麻煩，最後只得查詢部落格和相關文章去尋求幫助。然後又發現我的整個方法完全錯了，還不如從頭開始更容易點。所以從長遠來看，在專案開始時多做點研究反而會節省時間。
10、StackOverflow上有好心人或許能幫助我
我已經數不清有多少次，遇到問題都是通過StackOverflow得到解決的。只要你提出問題，社群裡就會有很多聰明，友好的熱心人願意幫助你。所有的線上論壇裡，它絕對是支援軟體程式設計和前後端web開發的最全面的網站。
11、這個問題竟然就因為少了個右括號
除錯是我們經常要用的方法，向前兩步，回退一步，再向前兩步，如此反覆。為了查詢函式命名或者變數作用域等錯誤，盯著程式碼看了數個小時，結果發現只是缺少了一個括號，你會有種哭笑不得的感覺。所有的時間都浪費在了一個小小的語法錯誤上，那一刻，你會覺得自己既是天才，又是傻子。
12、喝杯咖啡，休息一下
有的時候你需要起身離開顯示器，連續敲了幾個小時的鍵盤，如果中間休息一下，會對你的身體有益。大多數健康指南都建議每30-60分鐘休息一次。但是還是要取決於你的需要，如果你感覺中間暫停去休息會打斷你的思維，讓你很不爽，那就最好不要了。
13、我應該先把這個專案放一放，稍後在處理它
休息的另一種方式就會暫停你手中的專案，而不是離開你的電腦桌。或許你還有其他的工作要做，那就繼續下一項任務。比起試圖在一個花了5個小時還沒解決的問題上繼續掙扎，這會是一種更合理地分配時間和資源的方式。
14、我在想或許古典音樂能夠激發我的程式設計潛能呢
有一種說法認為古典音樂能促進植物的早期生長，我個人更偏愛古典音樂錯綜複雜的註解和音樂理論。爵士，鋼琴，大型樂隊，優雅的音樂在全球各地的人類文化都佔有一席之地。所以程式設計的時候聽點美妙的音樂會讓你除錯起來更得心應手呢。當然也有可能，會讓你更加心煩意亂。
15、或許現在是驗證鮑爾默峰值理論的好時機
我相信很多讀者都知道鮑爾默峰值，它是根據一個特殊的XKCD漫畫得來的。簡單來說，這個理論認為程式設計師的編碼能力在喝了定量的酒後，會達到一個峰值。這個起源於SteveBallmer的些古怪滑稽的姿態被認為是像一個醉漢在說胡話。儘管這有點諷刺，因為鮑爾默在微軟從來算不上一個真正的程式設計師，猜想我們只有等其他人來實踐這個理論了。
16、是誰動了我的程式碼？
這個聽起來有點像妄想症，但是有時候你很想知道是誰趁你補覺的時候寫的這些東西。回顧過去幾周或者幾個月的專案，會給你一種暈乎乎的感覺。有時候你會不記得你寫過這些東西—儘管上週你還在參與這個專案。好像是我很瘋狂地寫的程式碼，你卻從來不知道…
17、完全不知道這是神馬東東
你遇到的最糟糕的情況應該是在研究原始碼時，完全不知道它是在幹什麼，可能是來自你自己的專案，也可能是其他人的專案，但是問題都一樣。這個時候，你必須確定是否值得花費更多的時間去尋找其它解決方案或者仔細剖析程式碼，研究它到底是幹什麼的。
18、直接google下錯誤提示
鑑於多年的PHP經驗，我不得不說Google真的是除錯問題的最好的小夥伴。這對於Objective-C，C++，Java和其他的主流語言的境況一定是相同的。錯誤提示資訊對我們很有用，但是你必須記住不同的錯誤程式碼代表什麼意思。它讀起來更像是被翻譯過的計算機語言。幸好有這麼多線上支援，讓我們確定這些錯誤資訊代表的真正意思。
19、今天應該到此為止了，可我真的想把這個問題解決了
我們都知道想要退出時的那種極度沮喪的感覺，但是同時又覺得放棄不是正確的選擇。你很想繼續前進，找出新的解決方案來。但是如果到最後還是浪費了一個小時，那該怎麼辦？我對這種情況並不陌生，它會讓人特別沮喪。
20、哦買糕的，為什麼我都沒寫註釋呢
如果涉及到最基本的前端程式碼HTML/CSS/JS時，並不需要總是寫註釋。但是如果是比較複雜的指令碼和程式時，就需要寫一些標準的註釋以便你幾個月，甚至幾年後來重溫這些程式碼。有時候你會忘記給函式，引數，輸出格式以及其他重要的資料寫註釋，這無疑會導致發生bug時你不得不除錯整個指令碼去尋求解決方案，感到非常困惑，到那個時候你會覺得要是有一些有用的註釋該多好啊。
21、這個20分鐘之前還好好的呢
或許構建程式時最讓人沮喪的是，明明剛才還好好的東西，沒有改過任何程式碼，這會兒卻執行不起來了。我發誓這種情況絕對有發生，而且它沒有任何意義—也許其它程式執行的是快取版本呢然後也有一些時候我們只更新了一丁點程式碼，結果整個程式都崩潰並且完全停止執行。那就會回退到最新的備份版本，從那兒繼續吧。
22、忘了一個該死的分號，整個程式都崩了
幾乎我用過的所有的程式語言都要求每行結束時都要有結束符，但並不是所有的語言都這樣，不過C/C++系列語言絕對是這樣。當你忘記新增分號結束符時，這是多明顯的錯誤！但是解析器並不不理解，便丟擲一個致命的錯誤。接下來就得再花費20分鐘時間去研究程式碼，查詢技術錯誤。最終發現只是少了一個分號。哈，這就是軟體除錯的樂趣。
23、我想要招人來幫我修復bug，得花多少錢哪
僱傭程式設計師的想法聽起來很誘人，但顯然在經濟上是不可行的。另外，如果你連自己的的錯誤都沒解決，你又怎麼能從這些錯誤中學到東西呢？經歷多次失敗，最後當你真正理解了程式設計的概念後，你會很有成就感。但有時候腦子裡難免還是會閃過這種想法。
24、快速瀏覽下HackerNews，肯定能提高我的效率
很多程式設計師對於瀏覽軟體和創業等社會新聞的偏愛選擇都是HackerNews首頁。它有大量的關於自由職業，時間管理，軟體開發，創業釋出和籌資資金等方面很棒的資訊。儘管HN能夠模擬出通過自我教育更加高效的感覺，但其實是在浪費你的時間。每隔幾小時去快速瀏覽下新聞也沒那麼糟糕。
25、這個API怎麼沒有說明文件啊？
最讓人沮喪的事情就是使用外掛或者框架時，自帶的文件很糟糕，你只好自己去深入閱讀原始碼。我更喜歡讓開發人員花時間專門為專案設計一個文件頁，對所有的引數和選項都給予解釋，有可能的話，給出一些示例程式碼。但是很遺憾，這種情況幾乎不可能。所以最簡單的辦法就是遠離那些附帶文件很糟的工作，以免給自己帶來麻煩。
26、我真希望我已經對資料庫進行備份了
在編寫和除錯程式碼的時候，我有時候會想不到備份。然而，資料備份能夠幫助我們回退到做出某個特定的改變之前的版本，這對一個即時的伺服器環境是特別有用的，有些變化瞬間就會發生。切記在本地保留對網站檔案和資料庫的拷貝，以備急需。你可能會覺得這樣太麻煩了，但是總比你重建一個SQL資料庫強多了。
27、怎樣才能快速解決這個問題？
如果花費了數小時後，仍然未找到一個解決辦法，很明顯你需要一個新的方案了。程式設計師總是想要先實現功能，然後再去設計和美化介面。先確定一個最快的，最準確的解決方案，並盡力去實現和完成，然後再去考慮美化介面的問題就會很輕鬆了。
28、我敢打賭，你更新下我的程式碼，這個問題就解決了
那些為程式語言提供依賴包和外掛的團隊並不需要頻繁地釋出產品。有時候從本地傳送檔案到伺服器的時候，更新PHP/Ruby/Python/SQL版本可能會解決一些除錯問題。除非你的版本實在太舊了，否則本地更新很少能夠幫助你修復原始碼中的bug，不過還是值得一試！
29、我真的該好好學習Git了，…還是下週吧
開源的版本控制控制軟體Git在程式設計師中廣受歡迎。跟其他競爭對手相比，它提供了一條更簡單的學習曲線，被應用在了許多線上倉庫像Github和Bitbucket中。可能對初學者來說，會有點難度，但是一旦你掌握了基本命令，你會發現使用GIt就是小菜一碟。它還讓版本控制更加清晰。
30、算了，我還是從頭開始吧
有時候嘗試了數小時的解決方案後，你可能需要將你的工作檔案歸檔(或者刪掉它們)，重新開始。這個決定的最大難點就是你會考慮到前面數小時的工作會毫無收穫。但是如果你保留之前的想法，專案卻毫無進展時。重新開始，才有可能讓專案順利完成。