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

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