你的絕望我懂!工程師找 Bug 時一定有過的 30 句崩潰 OS | TechOrange 科技報橘
Search
Close this search box.

你的絕望我懂!工程師找 Bug 時一定有過的 30 句崩潰 OS

10481690626_be9f8793e7_z

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

我想分享一些工程師修復他們的原始程式碼時所經歷的想法。這是事情變得緊張時所觸發的輕鬆幽默。通常說來,應用程式終將可以工作,然後你也可以進入到下一個偉大的任務。我相信很多 web 開發人員和軟體工程師經歷過這些艱辛,然後在事後一笑而過。

  • 「我不知道是要刪掉還是要重寫它」

回顧從前舊的原始程式碼,會有一種想要重寫成較大塊集群的衝動和誘惑。醜陋的邏輯語句,還有冗長的語法,導致代碼非常難以閱讀!但話又說回來,如果代碼沒有壞掉的話,那就不要去修復它。這種洶湧澎拜的鬥爭是我經常要面對的,而且顯然會困擾許多軟體發展人員。

  • 「對於起始框架我應該查看Github

我想大多數開發人員都知道Github,上面每天都有數量驚人的開源項目發佈。任何語言的工程師都可以通過網路參考現有專案,加入維基討論,或者創建自己的代碼庫。它是各種專案所需外掛程式和範本的超棒資源。

  • 「為什麼這個腳本需要這麼多庫?」

尤其是一些比較大眾化的語言,如JavaObjective-C,庫的數量可能變得異常兇猛。當構建一個需要大量基礎的框架時,所需的庫的數量就變得顯而易見得多。即使是一些適用於JavaScript的外掛程式,也會額外需要無數的檔。有時,這會讓人覺得煩雜惱人但至少是有用的!

  • 「在網路某個地方一定已經有了解決方案。」

我面對棘手問題的第一反應是上網查。工程師會將他們遇到的問題發佈到論壇上,然後這個問題最終得到解決並歸檔。Google 可以指點你往正確的討論方向走。不幸的是,有的時候卻是因為手頭沒有特定問題的更多資訊,最後而找不到方向。

  • 「有沒有這個功能的外掛?」

為什麼要重新發明輪子?外掛程式是擴充任何程式或網站使用者介面的偉大資源。此外,它們還為開發人員提供了一些自訂和獨特的選項。萬一真的沒有可用外掛程式的話,沒什麼不自己構建一個呢?

  • 「雖然網站可以工作,但我害怕IE瀏覽器。」

Internet Explorer中渲染網頁的歷史充滿的艱辛考驗,是我們有目共睹或親身體驗過的。從5.5版本升級到IE9-IE10,總是需要爭取到更高級瀏覽器的支持。web開發人員可能會害怕 debug,因為在IE6中打開頁面是一個渲染噩夢。值得慶幸的是,這樣的日子正在慢慢成為過去。

  • 「對於邏輯運算式而言,這似乎並不怎麼合乎邏輯。」

對於if / else迴圈,for迴圈,while迴圈,do迴圈等等,都有邏輯運算式。當瀏覽示範代碼時,我試圖指出我的邏輯是如何工作的。NOT運算子和比較標記的數量又是如此之多。我經常回過頭去更新我自己的邏輯以便於更好地適合未來的做法。

  • 「我用30分鐘寫函數,花2小時讓它工作。」

這難道不像我們自己的程式設計故事嗎?你正興致勃勃地在構建著什麼,但是函數突然輸出致命的錯誤。所以,現在你必須回過頭去刪除一些代碼塊,以找出錯誤發生的行號。當你終於找到罪魁禍首,並解決它時,雖然有種精疲力竭的感覺,但也滿心安慰。

  • 「在閱讀多篇文章之後,我意識到,我之前全都是錯的。」

我常常會一開始就根據自己的程式設計思想,一頭紮進去研究,但是這可能會導致麻煩,如果事情不像原先設想地那樣順利的話。已經有很多次在我啟動一個項目之後,陷入了困境,然後只好尋求網路文章和其他論文的支持。然後我發現我的整個方法實際上是錯誤的,而且從頭來過更容易!如果我開始的時候能先做一番研究的話,從長遠來說,反而節省時間。

  • 「Stack Overflow 上和善的人或許願意幫助我。」

我已經數不清有多少次我通過Stack Overflow解決了難題。社區裡都是和善和聰明的人,他們非常願意提供幫助,如果你邁出第一步的話。在所有的線上論壇中,Stack Overflow絕對是對軟體程式設計以及前端/後端web開發支援最廣泛的網路。

  • 「花費大力氣才找出問題的原因是缺少了右括弧。」

調試是你必須要採取的步驟。進兩步,退一步。盯著代碼數個小時,以為函數名或變數作用域中有哪裡搞錯了,最後才發現是遺漏了一個括弧,這滋味,酸爽得不要不要的。所有這些時間都因為一個小小的語法錯誤而浪費。

  • 「喝杯咖啡,休息一下!」

有時候,你只是需要站起來,遠離螢幕。將滑鼠懸停在鍵盤數個小時,反而有助於打破常規。大多數健康指導都會建議我們每隔30-60分鐘休息一會。但是這一切都取決於你的需要,如果你覺得在程式中間休息更令人懊惱的話,那就不要中斷。

  • 「我應該把這個項目束之高閣,以後再來處理它。」

休息的另一個選擇是離開你的項目,而不僅僅是遠離你的電腦。如果還有其他工作需要做,那麼不妨去做其他工作。相對於已經花費了5個小時來解決問題依然不得入門而言的話,這將能更好地分配時間和資源。

  • 「我很懷疑古典音樂能否激發我的程式設計能力。」

有一種說法是,古典音樂可以在生命的早期階段促進植物生長。我個人非常喜歡在寫複雜筆記時聆聽古典音樂。爵士樂、鋼琴、大樂團,優雅的音樂在全世界的人類文化中都有一席之地。那麼,在程式設計的同時傾聽智慧的音樂真的能夠讓你更智慧地調試嗎?可能不會,不過希望它不會讓你變得更笨拙。

  • 「喝點酒吧,也許現在是檢驗峰值理論的好時機。」

很多讀者都聽說過峰值理論,簡單地說,這個理論認為程式師的編碼能力在喝了一定量的酒之後,會達到一個峰值。作者名叫史蒂夫·鮑爾默,他的行為古怪,就像是一個醉漢,這有一定的諷刺意味,因為鮑爾默在微軟從來就不是一名真正的程式師。也許我們需要等待別人來實踐證明這個理論吧。

  • 「是不是有人動過了我的原始程式碼?」

這聽起來有點妄想和偏執,但有時你會不由自主地懷疑,是不是有人在你補眠的時候,寫過這個東西了。回顧過去幾周或幾個月做的項目會讓你的心不斷地往下沉。有時候你會發現一些你已經不記得添加的東西——甚至這個項目你最近一周才剛剛瀏覽過!我為代碼而瘋狂,但你永遠不會知道

  • 「我不知道這意味著什麼。」

你能遇到的最壞情況是,你對你正在瀏覽的原始程式碼完全不知道該怎麼做。可能是你自己的項目,也可能是別人的專案,但問題的根源是相同的。現在,你必須決定是否值得花更多的時間去搜索替代方案,或仔細檢查腳本以瞭解它是如何工作的。

  • 「我需要Google錯誤資訊」

PHP中工作了多年之後,我不得不說,Google是我調試問題時的最好的朋友。使用Objective-CC ++JavaPython和其他主要語言,也是如此。錯誤資訊非常有説明,但是除非你記得不同的代碼意味著什麼,否則它讀起來更像是翻譯過的電腦語言。值得慶倖的是,有很多線上支援可以説明我們確定這些錯誤資訊的真正含義。

  • 「我應該停下來,收工……但我真的很想解決它!」

我們都有過極度灰心喪氣,想要放棄的感受,但總感覺半途而廢不是正確的選擇。於是,你繼續埋首鑽研,並嘗試新的解決方案來調試。但是,如果這還是意味著另一個小時的浪費呢?對於這樣的情況我並不陌生,令人非常令人沮喪。

  • 「噢,天哪,我以前為什麼不寫點注釋呢?」

當涉及到比較基礎的前端HTML / CSS / JS時,我們沒有必要寫注釋。但更複雜的腳本和程式卻需要一定形式的條理組織,當你在幾個月後,甚至若干年之後需要再回過頭來看的話。有時你會忘記注釋函數及其參數、輸出格式,和其他的必要資料。這在一段時間之後無疑會導致混亂,而且,當bug開始出現時,你必須調試整個腳本來尋找解決方案。因此,要是有一些有幫助的注釋就會讓你獲益良多。

  • 「20 分鐘前它還可以工作的……

在構建程式時,可能最令人沮喪的部分就是,它從能工作到不能工作——而你沒有更新代碼的任何部分!我發誓這是真的。而且這是沒有任何意義的事情——也許是其他程式正在運行緩存版本?有很多次你更新了一丁點代碼,卻導致了整個程式崩潰出錯,完全停止了工作。恢復到最近可工作的複製檔,然後從那裡開始一步步前進。

  • 「只是忘記了一個分號,然而整個程式卻因此而轟然倒下」

幾乎所有我使用的程式設計語言都需要結束符。雖然不是所有的語言都有,但在C/C ++中是很常見的。忘記添加結束符,不過是一個很顯然的錯誤!但是解析器不知道這一點,它會拋出一個致命錯誤。於是,你不得不額外花20分鐘去搜索技術故障,而原本只需要用1秒鐘補上那個缺少的分號即可。嗯,這就是調試軟體的樂趣。

  • 「我不知道讓別人來修復我的代碼,得花多少錢?」

聘請另一個開發人員的點子是挺誘人的,但從財政上看顯然沒有那麼可行。而且如果你不親身體驗的話,又怎麼能從這些錯誤中學到東西呢?當你在經歷多次失敗之後,終於理解了某個程式設計概念的時候,那感覺真是棒極了。儘管如此,我的腦海裡依然時不時地有一種「讓別人來修復代碼」的沖頭。

  • 「快速瀏覽Hackers News可以提高我的工作效率」

很多工程師最喜歡閱讀Hackers News頭版。它有很多關於自由業、時間管理、軟體發展、以及創業發佈和融資的大量資訊。雖然HN可以通過自我教育讓你感覺自己變得更有效率,但同時它也會浪費你的時間。但每隔幾小時去快速瀏覽下Hackers News也不是那麼糟糕。

  • 「這個API怎麼沒有文檔?!」

在使用帶有壞文檔的外掛程式或框架時,最令人沮喪的是,你必須靠自己去深入鑽研原始程式碼。我喜歡開發人員花時間去專門設計可用文檔頁面的專案。所有的參數和選項都解釋得清清楚楚,甚至可能會被用在一些示例代碼片段中。但可悲的是,事實並非總是如此。所以最簡單的方法是遠離不良文檔,不自找麻煩。

  • 「我真希望我保存了那個資料庫的備份副本……

在編寫和 Debug 代碼時,我不會想到要備份。然而,資料備份提供了允許我們回過頭去修改的踏腳石。這在即時的伺服器環境中尤為有用,因為有什麼變化會立即執行。以防萬一,我們應該記得保存網站檔和資料庫的本機複本!雖然這會是一個惱人的任務,但其惱人程度遠遠比不上重建損壞的SQL資料庫。

  • 「讓它正常工作的最快解決辦法是什麼?」

在花費數個小時苦苦思考自訂的解決方案之後,很明顯你需要一種新的方法。在設計漂亮的介面之前,程式師率先想到的是讓功能正常工作。確定最快、最準確的解決方案,並實施這個解決方案讓其工作才是100%利用了時間。然後,再轉移到漂亮美觀方面。

  • 「我敢打賭更新我的軟體將解決這個問題。」

管理程式設計語言依賴和外掛程式的團隊並不需要經常發佈版本。有時,在你從電腦傳輸檔到即時伺服器的時候,更新PHP /Ruby/ Python / SQL版本可以解決調試問題。本地更新很少能夠幫助修復原始程式碼中的bug,除非你的版本已經過時得無可救藥。所以,值得一試!

  • 「我應該更有條理並且去學習Git ……下周就去研究它。」

開源版本控制包Git在程式師中非常受歡迎。相對于其他的競爭對手,它提供了更容易的學習曲線,並且被許多線上代碼倉庫,如Github上和Bitbucket使用。開發人員很容易拖延去學習Git的行動,因為它對於初學者而言顯然是有難度的。但是一旦你知道了基本命令,那麼Git就是小菜一碟。而且它還能使調試版本控制更加清晰。

  •  「算了,我還是從頭再開始吧。」

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

(本文獲《碼農網》授權刊登轉載,圖片來源:dumbledad CC Licensed,未經授權請勿轉載。)