程序員篇——Bug出現了，你是怎樣應對的？

應用程序開發是一件十分有壓力的作業。代碼中出現bug是相當普遍的現象。面臨bug，一些程序員會生氣，會懊喪，會心慌意亂，乃至會心灰意懶，而另一些程序員會仍然堅持冷靜冷靜。因而，怎樣處理修正bug的過程也值得咱們細細琢磨。
這兒想給大家分享一些程序員修正他們的源代碼時所經歷的想法。這是作業變得緊張時所觸發的輕松詼諧。一般說來，應用程序終將能夠作業，然后你也能夠進入到下一個巨大的使命。
我信任很多網站開發人員和軟件工程師經歷過這些艱苦，然后在事后一笑而過。

1.“我不知道是要刪去仍是要重寫它”
回顧從前老的源代碼，會有一種想要返工寫成較大塊集群的沖動和誘惑。丑陋的邏輯語句，還有冗長的語法，導致代碼十分難以閱覽！但話又說回來，假如代碼沒有壞掉的話，那就不要去修正它。這種洶涌澎拜的斗爭是我常常要面臨的，而且明顯會困擾許多軟件開發人員。
2.“關于起始結構我應該檢查Github”
我想大多數開發人員都知道Github，上面每天都有數量驚人的開源項目發布。任何言語的程序員都能夠經過互聯網學習現有項目，加入維基評論，或者創建自己的代碼庫房。它是各種項目所需插件和模板的超棒資源。
3.“為什么這個腳本需求這么多庫？”
尤其是一些比較大眾化的言語，如Java和Objective-C，庫的數量或許變得異常兇狠。當構建一個需求很多基礎的結構時，所需的庫的數量就變得清楚明了得多。即使是一些適用于JavaScript的插件，也會額定需求無數的文件。有時，這會讓人覺得煩雜惱人——但至少是有用的！
4.“在互聯網的某個地方一定現已有了處理計劃?！?br> 我面臨扎手問題的第一反應是上網查。程序員會將他們遇到的問題經過帖子發布到論壇上，然后這個問題最終得到處理并歸檔。谷歌搜索問題關鍵字的好幫手，能夠點撥你往正確的評論方向走。不幸的是，有的時分卻是由于手頭沒有特定問題的太多信息而找不著北。
5.“有沒有這個功用的插件？”
為什么要重新創造輪子？插件是擴展任何程序或網站用戶界面的巨大資源。此外，它們還為開發人員供給了一些自定義和獨特的選項。萬一真的沒有可用插件的話，沒什么不自己構建一個呢？
6.“盡管網站能夠作業，但我懼怕IE閱覽器?！?br> 在Internet Explorer中烘托網頁的前史充滿的艱苦檢測，是咱們有目共睹或親身體驗過的。從5.5版別升級到IE9-IE10，總是需求爭取到更高檔閱覽器的支撐。web開發人員或許會懼怕調試網頁，由于在IE6中翻開頁面是一個烘托噩夢。值得幸虧的是，這樣的日子正在漸漸成為曩昔。
7.“關于邏輯表達式而言，這好像并不怎樣合乎邏輯?！?br> 關于if / else循環，for循環，while循環，do循環等等，都有邏輯表達式。當閱覽示例代碼時，我企圖指出我的邏輯是怎樣作業的。NOT運算符和比較標記的數量又是如此之多。我常?；剡^頭去更新我自己的邏輯以便于更好地適合未來的做法。
8.“我用30分鐘寫函數，花2小時讓它作業?！?br> 這難道不像咱們自己的編程故事嗎？你正興致勃勃地在構建著什么，可是突然之間，函數輸出了一個喪命的過錯。所以，現在你必須回過頭去刪去一些代碼塊，以找犯過錯發生的行號。當你總算找到罪魁禍首，并處理它時，盡管有種精疲力竭的感覺，但也滿心安慰。
9.“在閱覽多篇博客文章之后，我意識到，我之前全都是錯的?！?br> 我常常會一開端就依據自己的編程思想，一頭扎進去研討，可是這或許會導致麻煩，假如作業不像原先設想地那樣順利的話?，F已有很屢次在我啟動一個項目之后，陷入了困境，然后只好尋求博客和其他論文的支撐。然后我發現我的整個辦法實際上是過錯的，而且從頭來過更簡單！假如我開端的時分能先做一番研討的話，從長遠來說，反而節省時刻。
10.“Stack Overflow上和藹的人或許樂意幫助我?！?br> 我現已數不清有多少次我經過Stack Overflow處理了難題。社區里都是和藹和聰明的人，他們十分樂意供給幫助，假如你邁出第一步的話。在一切的在線論壇中，Stack Overflow絕對是對軟件編程以及前端/后端web開發支撐最廣泛的網絡。
11.“花費大力氣才找出問題的原因是缺少了右括號?！?br> 調試是你必須要采取的過程。進兩步，退一步。盯著代碼數個小時，以為函數名或變量效果域中有哪里搞錯了，最終才發現是遺漏了一個括號，這味道，酸爽得不要不要的。一切這些時刻都由于一個小小的語法過錯而糟蹋。
12.“喝杯咖啡，歇息一下！”
有時分，你僅僅需求站起來，遠離顯示器。將鼠標懸停在鍵盤數個小時，反而有助于打破常規。大多數健康輔導都會主張咱們每隔30-60分鐘歇息一會?？墒沁@一切都取決于你的需求，假如你覺得在程序中心歇息更令人懊喪的話，那就不要中止。
13.“我應該把這個項目置之不理，以后再來處理它?！?br> 歇息的另一個挑選是脫離你的項目，而不僅僅是遠離你的電腦。假如還有其他作業需求做，那么無妨去做其他作業。相關于現已花費了5個小時來處理問題仍然不得入門而言的話，這將能更好地分配時刻和資源。
14.“我很置疑古典音樂能否激發我的編程才能?！?br> 有一種說法是，古典音樂能夠在生命的前期階段促進植物生長。我個人十分喜愛在寫雜亂筆記時傾聽古典音樂。爵士樂、鋼琴、大樂團，優雅的音樂在全世界的人類文明中都有一席之地。那么，在編程的一起傾聽才智的音樂真的能夠讓你更才智地調試嗎？或許不會，不過期望它不會讓你變得更笨拙。
15.“喝點酒吧，或許現在是查驗鮑爾默峰值理論的好時機?！?br> 很多讀者都聽說過鮑爾默的峰值理論，依據一個特殊XKCD漫畫而得出。簡略地說，這個理論以為程序員的編碼才能在喝了一定量的酒之后，會達到一個峰值。作者名叫史蒂夫·鮑爾默，他的行為乖僻，就像是一個醉漢，這有一定的挖苦意味，由于鮑爾默在微軟歷來就不是一名真實的程序員?；蛟S咱們需求等候他人來實踐證明這個理論吧。
16.“是不是有人動過了我的源代碼？”
這聽起來有點妄想和偏執，但有時你會不由自主地置疑，是不是有人在你補覺的時分，寫過這個東西了?；仡欔傥魩字芑驇讉�月做的項目會讓你的心不斷地往下沉。有時分你會發現一些你現已不記住增加的東西——乃至這個項目你最近一周才剛剛閱覽過！我為代碼而瘋狂，但你永久不會知道…
17.“我不知道這意味著什么?！?br> 你能遇到的最壞狀況是，你對你正在閱覽的源代碼徹底不知道該怎樣做?；蛟S是你自己的項目，也或許是他人的項目，但問題的根源是相同的?，F在，你必須決定是否值得花更多的時刻去搜索代替計劃，或仔細檢查腳本以了解它是怎樣作業的。
18.“我需求Google過錯信息?！?br> 在PHP中作業了多年之后，我不得不說，Google是我調試問題時的最好的朋友。運用Objective-C、C ++、Java、Python和其他首要言語，也是如此。過錯信息十分有幫助，可是除非你記住不同的代碼意味著什么，否則它讀起來更像是翻譯過的計算機言語。值得幸虧的是，有很多在線支撐能夠幫助咱們確認這些過錯信息的真實意義。
19.“我應該停下來，收工……但我真的很想處理它！”
咱們都有過極度心灰意懶，想要放棄的感觸，但總感覺功敗垂成不是正確的挑選。于是，你繼續埋首研討，并測驗新的處理計劃來調試?？墒?，假如這仍是意味著另一個小時的糟蹋呢？關于這樣的狀況我并不生疏，令人十分令人懊喪。
20.“哦，天哪，我以前為什么不寫點注釋呢？”
當涉及到比較基礎的前端HTML / CSS / JS時，咱們沒有必要寫注釋。但更雜亂的腳本和程序卻需求一定形式的條理安排，當你在幾個月后，乃至若干年之后需求再回過頭來看的話。有時你會忘掉注釋函數及其參數、輸出格局，和其他的必要數據。這在一段時刻之后無疑會導致紊亂，而且，當bug開端出現時，你必須調試整個腳本來尋覓處理計劃。因而，要是有一些有幫助的注釋就會讓你獲益良多。
21.“20分鐘前它還能夠作業的……”
在構建程序時，或許最令人懊喪的部分就是，它從能作業到不能作業——而你沒有更新代碼的任何部分！我立誓這是真的。而且這是沒有任何意義的作業——或許是其他程序正在運行緩存版別？有很屢次你更新了一丁點代碼，卻導致了整個程序潰散犯錯，徹底中止了作業?？祻偷阶罱�可作業的復制文件，然后從那里開端一步步前進。
22.“僅僅忘掉了一個分號，然而整個程序卻因而而轟然倒下?！?br> 簡直一切我運用的編程言語都需求結束符。盡管不是一切的言語都有，但在C/C ++中是很常見的。忘掉增加結束符，不過是一個很明顯的過錯！可是解析器不知道這一點，它會拋出一個喪命過錯。于是，你不得不額定花20分鐘去搜索技術毛病，而原本只需求用1秒鐘補上那個缺少的分號即可。嗯，這就是調試軟件的趣味。
23.“我不知道讓他人來修正我的代碼，得花多少錢？”
延聘另一個開發人員的點子是挺誘人的，但從財政上看明顯沒有那么可行。而且假如你不親身體驗的話，又怎樣能從這些過錯中學到東西呢？當你在經歷屢次失利之后，總算理解了某個編程概念的時分，那感覺真是棒極了。盡管如此，我的腦海里仍然時不時地有一種“讓他人來修正代碼”的沖頭。
24.“快速閱覽Hackers News能夠進步我的作業功率?！?br> 很多程序員最喜愛閱覽的，有關于軟件和創業公司等社會新聞的挑選是Hackers News頭版。它有很多關于自由職業、時刻管理、軟件開發、以及創業發布和融資的很多信息。盡管HN能夠經過自我教育讓你感覺自己變得更有功率了，但一起它也會糟蹋你的時刻。每隔幾小時去快速閱覽下Hackers News也不是那么糟糕。
25.“這個API怎樣沒有文檔？！”
在運用帶有壞文檔的插件或結構時，最令人懊喪的是，你必須靠自己去深化研討源代碼。我喜愛開發人員花時刻去專門規劃可用文檔頁面的項目。一切的參數和選項都解說得清清楚楚，乃至或許會被用在一些示例代碼片段中。但可悲的是，現實并非總是如此。所以最簡略的辦法是遠離不良文檔，不自找麻煩。
26.“我真期望我保存了那個數據庫的備份副本……”
在編寫和調試代碼時，我不會想到要備份。然而，數據備份供給了答應咱們回過頭去修正的踏腳石。這在實時的服務器環境中尤為有用，由于有什么變化會當即履行。以防萬一，咱們應該記住保存網站文件和數據庫的本地副本！盡管這會是一個惱人的使命，但其惱人程度遠遠比不上重建損壞的SQL數據庫。
27.“讓它正常作業的最快處理辦法是什么？”
在花費數個小時苦苦思考自定義的處理計劃之后，很明顯你需求一種新的辦法。在規劃美麗的界面之前，程序員首先想到的是讓功用正常作業。確認最快、最精確的處理計劃，并施行這個處理計劃讓其作業才是100％利用了時刻。然后，再轉移到美麗美觀方面。
28.“我敢打賭更新我的軟件將處理這個問題?！?br> 管理編程言語依靠和插件的團隊并不需求常常發布版別。有時，在你從計算機傳輸文件到實時服務器的時分，更新PHP /Ruby/ Python / SQL版別能夠處理調試問題。本地更新很少能夠幫助修正源代碼中的bug，除非你的版別現已過時得無可救藥。所以，值得一試！
29.“我應該更有條理而且去學習Git ……下周就去研討它?！?br> 開源版別操控包Git在程序員中十分受歡迎。相關于其他的競爭對手，它供給了更簡單的學習曲線，而且被許多在線代碼庫房，如Github上和Bitbucket運用。開發人員很簡單拖延去學習Git的行動，由于它關于初學者而言明顯是有難度的?？墒且坏┠阒�道了根本指�?，那么Git就是小菜一碟。而且它還能使調試版別操控愈加清晰。
30.“算了，我仍是從頭再開端吧?！?br> 有時分，在你絞盡腦汁花費數個小時之后，或許要做的僅僅將你的作業文件移動到歸檔目錄（或刪去它們），再從頭開端就能夠了?？墒?，考慮到從前現已消耗的時刻，你很難下定這個決心?？墒?，當我束手無策時，我往往會挑選從頭開端，由于這樣才有或許找到完結項目的正確道路。