開發應用程序是一個很有壓力的工作.沒有人是完美的,在工作中遇到bug是相當平凡的.有些程序員會憤怒，沮喪，心煩意亂，甚至氣餒，但是有一部分人會非常冷靜。我們如何處理修復bug的過程中，是值得推敲的。
我想分享一些程序員在努力修復自己代碼中的bug時的口頭禪和主意.當事情變的緊張時,這些總會顯的輕鬆幽默.一般情況下,應用也會正常運行,你也可以繼續下一個工作任務.
我相信很多Web開發人員和軟件工程師都會遇到這些問題,而且事後還在笑。
1.“我不知道是該刪除還是重編寫。”
迴歸歷史源代碼會誘使程序員重新產生更多的障礙集羣。邏輯性差的冗餘句法令人無法理解！然而，如果它沒有中斷，請不要去修復。這是我經常掙扎的問題，相信也困擾了不少其他軟件開發員。
2.“我應該在開始架構時檢查Github版本控制系統。”
絕大多數開發員都應該知道Github版本控制系統及每天公佈的開源項目。涉足所有計算機語言的程序員，利用網絡分解研究現有項目，進行維基論壇討論或發表個人的代碼報告。這些爲很多項目的插件和模板提供了很多很好的資源。
3."爲什麼這個腳本需要如此多的庫"
尤其是變得越來越重量級例如 java和Objective-C，庫文件的數量日益增加。非常明顯的是當建立一個框架時就需要許多的基礎庫。甚至一些JavaScript的插件都需要大量額外的文件。有的時候雜七雜八的東西很招人煩 -但至少它能運行。
4“在互聯網上移動一定會有解決方法”
遇到困難問題我的第一反應是在互聯網上查找。許多的程序員會把他們遇到的問題發佈到論壇上，問題最終得到解決並保存下來。谷歌極好的挑選出你問題相關的關 鍵字並且爲你指出了正確的導向，這些都爲討論提供了有益的線索。不幸的是，有的時候對於一個特定的問題還沒有過多的信息。
5.“有這個功能的插件麼？“
爲什麼要重造輪子？插件是擴展任何程序或網站用戶界面的一個很好的資源。另外他們可以爲開發者使用的一些定製的獨特的選項。如果不存在已有插件的話，爲什麼不自己創建一個呢？
6.“網站項目，我害怕Internet Explorer。”
使用Internet Explorer渲染網頁時遇到的坑我就不提了。從5.5版本到IE9-IE10瀏覽器支持方面的爭議一直不斷。Web開發人員可能害怕網頁調試，使用IE6渲染更是噩夢。謝天謝地，那些日子已經慢慢成爲了過去。
7.“邏輯語句——它本身就不是很有邏輯。”
現在有的邏輯語句有if/else循環、for循環、while循環、do循環……這個列表相當長。當查看一些舊示例代碼時我盡力想弄明白我當時的使它運行的邏輯是什麼。NOT操作的跳轉數及比較符讓人頭暈。以後我會經常回過頭來更新自己好的邏輯實踐。
8.“我花30分鐘寫一個函數，卻要花2小時讓它工作。”
這不是十年前的故事嗎？你沿着以前的套路輕鬆構建，突然函數輸出了一個致命的error，因此你不得不回過頭去清除代碼塊來試圖找到故障的代碼行。當你筋疲力盡最終找到了罪魁禍首後就像得到救贖一樣。
9.“讀了幾個博客後我才意識到我之前的理解一直是錯誤的。”
我喜歡按自己的編程思想直奔主題，當事情沒有按計劃進行時這樣做會導致麻煩。很多次我開始了一個項目後就陷入困境，然後便到博客或相關文章中尋求幫助。之後我發現整個方法實際上是錯誤的，重新開始會更容易！開始時多一點研究在長遠看來是在節省時間。
10.“Stack Overflow上的好心人會幫助你。”
我已經數不清有多少次通過Stack Overflow解決困難的問題了。勇敢邁出第一步的話社區裏有很多聰明的熱心人願意幫你。所有的在線論壇被定義爲是軟件開發者及前端/後端web工程師最全面的支持網。
11. “忘記關閉結束括號帶來的麻煩”
你採取的所有步驟都是調試。向前兩步，退回一步，或者向前更多。你會感覺花很多時間盯着代碼，只爲查找一些語法錯誤或者是變量的作用域，最終卻只找到一個失蹤的括號，這是一種奇怪的感覺。所有的時間都花費在了一個小小的語法錯誤上。在同一時間會感覺自己即是一個天才又是一個傻子。
12. “停下來，喝一杯咖啡”
有時候你需要的是起身離開顯示器，在鍵盤上工作幾個小時後。這有助於打破慣例。大多數的健康指南建議休息30-60分鐘。但這一切都取決於你的需要，如果讓你從編程過程中中斷會使你苦惱，那最好還是不要中斷。
13.“我應該把這個項目先放一放，稍後再處理它。”
工作間歇停頓的一種可選方式是遠離你的項目，而不僅僅是你的電腦。也許存在另外一個需要你完成的工作，那麼就過去把那項工作挑出來瞧一瞧吧。相比於你已經心迷神亂的死盯着要解決的另外一個問題而言，這也許是對時間和資源的一種更加好的分配方式。
14."我想古典音樂興許能激發我的編程潛能"
有一種觀點認爲古典音樂能夠在作物生命的早期階段促進其生長。我個人則偏愛於古典音樂繁富的附註和錯綜複雜的音樂理論。爵士，鋼琴，大型的樂隊，優雅的音樂在世界各地的人文中都佔有一席之地。那麼在編程的時候聽聽輕妙的音樂會不會也能讓你更精於調試之道呢？或許不會，但願它不然讓你更加的笨拙。
15.“也許現在正是驗證Ballmer峯值理論的好時機”
我想很多讀者都知道 Ballmer峯值，它由一個特殊的xkcd漫畫創造而來。簡而言之，這一理論表明程序員的編碼能力會在消費了特定量的酒精之後達到一個頂峯。這源起於Steve Ballmer的古怪動作滑稽的像個酒鬼寫出了隨筆，儘管這有某些諷刺意味，因爲Ballmer在微軟從來都不是一個真正的程序員。試想我們將不得不等待另外一個人來爲這一理論進行一次試運行。
16."是不是有人正在擺弄我的代碼"
這聽起來像是妄想和偏執，但有時你只是猜想誰在你正忙着睡覺的時候挖了這個坑。遍覽過去幾周或者幾個月的項目能夠給你留下一種病態的感覺。有時候你將會發 現你這從來都不記得是自己留下的坑——儘管上個星期你都搗騰過這個項目！我發了瘋似得把它寫下來，但是你從來不知道...
17.“我不知道這意味着什麼。“
你能遇到的最糟糕的情況就是看一看代碼，完全不知道所以然。這可能來自於你自己的項目，也可能是其他什麼人的項目，但都是同樣的問題。現在你不得不去決定是否值得花更多的時間尋找替代方案，或者剖析代碼以瞭解其工作原理。
18.”那段錯誤消息我需要查查Google才行“
多年PHP的工作經歷過後，我不得不承認Google是我在調試問題時的最好夥伴。Objective-C、C++、
Java、Python和其他主流的語言的境況絕對都是相同的。錯誤消息嘗試能對程序員有所幫助，但是除非你對不同的代碼意味着什麼牢記於心，否則它讀起來則更加像是被翻譯過的計算機語言。謝天謝天線上有那麼多的幫助支持，而我們只需決定這些錯誤消息真正確切的意義。
19.”我應該停下來，把它放上一天...但是我真心想把它弄出來啊！“
我們都知道那種在你想要退出時極度沮喪的感覺，但只是感覺上像是放棄並不是正確的選擇。你想要不斷的推進，並在調試中嘗試新的解決方案。但是如那最終證明是浪費了另外一個小時呢？我對這種境況並不陌生，它可是非常令人沮喪的。
20.”噢親愛的，爲啥我不寫下任何註釋呢？“
如果涉及到更加基礎的HTML/CSS/JS時，並不常常是要留下注釋的。但是更加複雜的腳本和程序則需要某些形式的組織結構，以便你在幾個月之後，或者 甚至是十多年之後再來重溫這些東西。有時候你會忘記對函數和它們的參數、輸出形式和其它重要的數據加上註釋。這無疑將會導致在bug開始出現而你不得不調 試整個腳本以找出解決方案的時候陷入迷途。那時候你就會抱怨如果僅僅有一些有用的註釋該多好。
21.“這在20分鐘之前還是起作用的呀...”
也許構造程序的時候最令人迷惑的部分就是當它變得有時運行又有時不能運行的時候——代碼的任何部分都沒有任何改動！我發誓這絕對發生過。而且它並沒有任何 意義——也許其它程序正運行着一個緩存的版本？隨後有一次只更新了一點點代碼導致了整個程序由於錯誤而奔潰並且立即完全停止了工作。這時候就回滾到最近一 次的工作備份上來，並且從那裏開始繼續前進吧。
22.“你忘掉了一個糟糕的分號，整個程序就這樣一下子崩掉了。”
我所用過的幾乎每一種語言都需要一個符號作爲一行的終止。它們並不都是這樣的，但在C/C++家族中絕對是普遍如此的。當你忘記加上一個終止的分號時，它會是一個誠實的錯誤！但是解析器對此並不理解，而會拋出了一個致命的錯誤。現在你不得不爲一個技術錯誤花另外20分鐘挖掘代碼，而它僅僅是一個分號的遺失。啊，這就是調試軟件的樂趣。
23.“我在想花錢找人幫我修復這個問題得花費多少？”
鋪天蓋地的招聘額外開發者的想法是很誘人的，但很顯然其可行性不及財務上的可行性。再加上如果不是你自己把手弄髒的，那你怎麼從所有這些錯誤中學到教訓？當你在許多次失敗以後，最終理解了一個編程的概念時將會很有成就感。但這種思想並不總是能在我的腦海閃過。
24.“快速的瀏覽一下Hacker News一定能提高我的效率。”
許多程序員最喜愛的有關軟件和初創公司的社會新聞是Hacker News 頭版。它有許多關於自由職業者，時間管理，軟件開發，還有啓動發佈會和資金籌集方面很棒的信息。儘管HN可以模擬出你自我教育而變得高效起來的感覺，它也是在消耗着你的時間的。每隔幾個小時再去快速的重新掃掃新聞應該不會那麼糟糕。
25. “這個 API 怎麼能沒有文檔呢?!”
使用一個具有糟糕文檔的插件或者框架時，最令人沮喪的事情是你不得不自己深入閱讀源代碼。我推崇的項目是，那些開發人員花時間特別設計出一個有用文檔頁的 項目。所有的參數與選項都被予以解釋，可能甚至會在一些案例代碼片段中使用出現。但是遺憾的是事實並不總是如此。最簡單的辦法就是遠離文檔貧乏的作業，以 免你自己陷入不幸。
26. “我當然希望我留下了那個數據庫的一份拷貝…”
在編寫代碼並進行調試的時候，我總是想不起備份。然而，數據備份提供了一個墊腳石，使我們可以回到我們實施了某種更改之前的時刻。對一個生產環境的服務器 這個特別有用，在那個環境中變化總是在瞬間完成的。記住保留網站文件和數據庫的本地拷貝，以備不時之需！這或許是很煩人的任務，但這也沒有比重新創建一個 被破壞的SQL數據庫更煩人。
27. “能讓這個正常工作的最快的解決方案是什麼?”
在東跌西撞的尋找了幾小時的自定義解決方法後，很明顯你需要一個新的方案了。程序員們都是希望功能正常運轉之後，再去考慮接口設計的優雅問題。要確定最快最準確的解決方案，並應用它使之儘快的開始工作。然後，就可以放鬆心情去追求程序的美感了。
28. “我打賭，升級一下我的軟件升級就能解決這個問題。”
那些管理着提供給編程語言使用的依賴包和插件的團隊，不需要頻繁的發佈產品。有時升級你的PHP/Ruby/Python/SQL版本可能會解決一些調試問題，比如在從你的電腦向在線服務器上傳文件的時候。除非你的版本實在是老的沒治了，否則做本機升級很少能幫你解決代碼中的bug。不過，還是值得一試!
29.“我應該學習並使用Git來組織代碼……但下個周吧……。”
開源代碼版本控制軟件Git在程序員中非 常受歡迎。相比其他競爭對手它提供了一條更容易的學習曲線，它已經被應用在了許多在線倉庫如GitHub和Bitbucket。開發者可能會改變主意因爲 對初學者而言它有條稍陡峭的入門曲線。但是一旦你瞭解了基本的命令Git便是小菜一碟。它使得使用版本控制來進行調試更加條理清晰。
30.“放棄這個，從頭開始。”
有時在嘗試了長時間解決方案後，你需要把你的工作文件轉移到歸檔目錄（或刪除），然後從頭開始。考慮到前一小時辛苦這確實是個艱難的決定。但當我謹記前車之鑑重新開始時這往往是項目走向完成所應該看到的。
原文鏈接：http://www.hongkiat.com/blog/things-programmers-say/
譯文鏈接：http://www.oschina.net/translate/things-programmers-say
【編輯推薦】
