發生問題時程式設計師最常見的 30 種反應

　　開發應用程式是一個很有壓力的工作.沒有人是完美的,在工作中遇到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/