程式員看到了bug

開發應用程式是一項壓力很大的工作，人無完人，工作中遇到bug是很正常的事，有些程式員會生氣，沮喪，郁悶，甚至洩氣，也有一些程式員則會比較淡定。如何進行修複bug的過程，是值得我們好好推敲的。

我想分享一些有關程式員在努力修複bug時常說的話和冒出的想法。當氛圍變得緊張的時候，這些話就會顯得輕松幽默。最終，bug也會修複成功，你将會繼續下一個任務。

我相信許多web開發人員和軟體工程師在程式設計中都會遇到困難，而事後回想起來，還會覺得很好笑。

1、我不知道該删掉還是重寫

回歸曾經寫的源代碼，總有一種想要重新返工的沖動，邏輯性差，備援代碼多，讓人難以了解。但是，如果功能沒出現問題，千萬不要去修改。這是我經常要面對的困擾，相信也困擾了其他不少的軟體開發者。

2、一開始架構時就該查Github

相信絕大多數開發人員都知道Github，它上面每天都會釋出的一些神奇的開源項目。涉足所有計算機語言的程式員，會利用網絡對現有項目進行分叉，在維基論壇談論或者回購他們自己的源代碼，這些都為各種各樣的項目的插件和模闆提供了很多豐富的資源。

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、算了，我還是從頭開始吧

有時候嘗試了數小時的解決方案後，你可能需要将你的工作檔案歸檔(或者删掉它們)，重新開始。這個決定的最大難點就是你會考慮到前面數小時的工作會毫無收獲。但是如果你保留之前的想法，項目卻毫無進展時。重新開始，才有可能讓項目順利完成。