困擾程序員的30種軟件開(kāi)發(fā)問(wèn)題，你是否時(shí)曾相識？

　　回歸曾經(jīng)寫(xiě)的源代碼，總有一種想要重新返工的沖動(dòng)，邏輯性差，冗余代碼多，讓人難以理解。但是，如果功能沒(méi)出現問(wèn)題，千萬(wàn)不要去修改。這是我經(jīng)常要面對的困擾，相信也困擾了其他不少的軟件開(kāi)發(fā)者。

　　相信絕大多數開(kāi)發(fā)人員都知道Github，它上面每天都會(huì )發(fā)布的一些神奇的開(kāi)源項目。所有語(yǔ)言的程序員都會(huì )利用網(wǎng)絡(luò )，為已存在的項目創(chuàng )建分支，添加項目wiki描述，或者創(chuàng )建自己的代碼庫，這些都為各種各樣的項目的插件和模板提供了很多豐富的資源。

　　說(shuō)到一些越來(lái)越被廣泛使用的計算機語(yǔ)言，像Java和Objective-C，庫文件的數量也不斷增加。很明顯可以看出，構建一個(gè)框架就需要許多的基礎庫，甚至一些Java的插件也需要很多大量的附加文件。有時(shí)候這些亂七八糟的東西會(huì )很讓人心煩，但是至少它能運行。

　　遇到困難時(shí)，我的第一反應就是上網(wǎng)查資料，很多程序員會(huì )在論壇上發(fā)布他們的問(wèn)題，最終這些問(wèn)題都會(huì )被解決并存檔。Google會(huì )很神奇地選擇一些跟你的問(wèn)題相關(guān)的關(guān)鍵字，你就能夠輕而易舉地得到一些對你有幫助的討論信息。不幸的是，有時(shí)候對于一些特定的問(wèn)題，相關(guān)的信息還不是很多。

　　何必要多此一舉插件是擴展任何程序或者網(wǎng)站用戶(hù)接口的很好的資源。另外它們還為開(kāi)發(fā)者提供了一些定制以及獨特的選項。如果沒(méi)有可用的插件，那你為什么不自己創(chuàng )建一個(gè)呢？

　　使用IE渲染網(wǎng)頁(yè)遇到的各種困難，我就不提了，從5。5版本到IE9-IE10，對于瀏覽器的支持問(wèn)題的爭議就一直不斷。Web開(kāi)發(fā)人員會(huì )很害怕網(wǎng)頁(yè)調試，使用IE6進(jìn)行渲染更是噩夢(mèng)。，幸好那些日子已經(jīng)慢慢成為歷史了。

　　有一些邏輯語(yǔ)句，像if/else循環(huán)，for循環(huán)，while循環(huán)，do循環(huán)…等等，還有很多。在回顧一些源代碼時(shí)，我總是盡力想弄明白我的邏輯是怎么回事。我經(jīng)常會(huì )回頭更新代碼，讓邏輯更清晰。

　　這不是十年前的一個(gè)有關(guān)編程的故事嗎？當一切都在按照你所所期待的順利進(jìn)行著(zhù)，突然某個(gè)函數輸出了一個(gè)致命的錯誤，所以你不得不回頭刪除代碼塊，試圖定位出錯的代碼行。盡管這會(huì )讓你筋疲力盡，但是一旦找到錯誤的原因，問(wèn)題解決之后，你又會(huì )立馬感到渾身輕松。

　　我總是喜歡根據自己的編程思想直入主題，但是如果事情沒(méi)有按照我原本的計劃進(jìn)行時(shí)，會(huì )導致很多麻煩。有很多次，我在做項目時(shí)，途中都遇到了麻煩，最后只得查找博客和相關(guān)文章去尋求幫助。然后又發(fā)現我的整個(gè)方法完全錯了，還不如從頭開(kāi)始更容易點(diǎn)。所以從長(cháng)遠來(lái)看，在項目開(kāi)始時(shí)多做點(diǎn)研究反而會(huì )節省時(shí)間。

　　我已經(jīng)數不清有多少次，遇到問(wèn)題都是通過(guò)StackOverflow得到解決的。只要你提出問(wèn)題，社區里就會(huì )有很多聰明，友好的熱心人愿意幫助你。所有的在線(xiàn)論壇里，它絕對是支持軟件編程和前后端web開(kāi)發(fā)的最全面的網(wǎng)站。

　　調試是我們經(jīng)常要用的方法，向前兩步，回退一步，再向前兩步，如此反復。為了查找函數命名或者變量作用域等錯誤，盯著(zhù)代碼看了數個(gè)小時(shí)，結果發(fā)現只是缺少了一個(gè)括號，你會(huì )有種哭笑不得的感覺(jué)。所有的時(shí)間都浪費在了一個(gè)小小的語(yǔ)法錯誤上，那一刻，你會(huì )覺(jué)得自己既是天才，又是傻子。

　　有的時(shí)候你需要起身離開(kāi)顯示器，連續敲了幾個(gè)小時(shí)的鍵盤(pán)，如果中間休息一下，會(huì )對你的身體有益。大多數健康指南都建議每30-60分鐘休息一次。但是還是要取決于你的需要，如果你感覺(jué)中間暫停去休息會(huì )打斷你的思維，讓你很不爽，那就最好不要了。

　　休息的另一種方式就會(huì )暫停你手中的項目，而不是離開(kāi)你的電腦桌�；蛟S你還有其他的工作要做，那就繼續下一項任務(wù)。比起試圖在一個(gè)花了5個(gè)小時(shí)還沒(méi)解決的問(wèn)題上繼續掙扎，這會(huì )是一種更合理地分配時(shí)間和資源的方式。

　　有一種說(shuō)法認為古典音樂(lè )能促進(jìn)植物的早期生長(cháng)，我個(gè)人更偏愛(ài)古典音樂(lè )錯綜復雜的注解和音樂(lè )理論。爵士，鋼琴，大型樂(lè )隊，優(yōu)雅的音樂(lè )在全球各地的人類(lèi)文化都占有一席之地。所以編程的時(shí)候聽(tīng)點(diǎn)美妙的音樂(lè )會(huì )讓你調試起來(lái)更得心應手呢。當然也有可能，會(huì )讓你更加心煩意亂。

　　我相信很多讀者都知道鮑爾默峰值，它是根據一個(gè)特殊的XKCD漫畫(huà)得來(lái)的。簡(jiǎn)單來(lái)說(shuō)，這個(gè)理論認為程序員的編碼能力在喝了定量的酒后，會(huì )達到一個(gè)峰值。這個(gè)起源于SteveBallmer的些古怪滑稽的姿態(tài)被認為是像一個(gè)醉漢在說(shuō)胡話(huà)。盡管這有點(diǎn)諷刺，因為鮑爾默在微軟從來(lái)算不上一個(gè)真正的程序員，猜想我們只有等其他人來(lái)實(shí)踐這個(gè)理論了。

　　這個(gè)聽(tīng)起來(lái)有點(diǎn)像妄想癥，但是有時(shí)候你很想知道是誰(shuí)趁你補覺(jué)的時(shí)候寫(xiě)的這些東西�；仡欉^(guò)去幾周或者幾個(gè)月的項目，會(huì )給你一種暈乎乎的感覺(jué)。有時(shí)候你會(huì )不記得你寫(xiě)過(guò)這些東西—盡管上周你還在參與這個(gè)項目。好像是我很瘋狂地寫(xiě)的代碼，你卻從來(lái)不知道…

　　你遇到的最糟糕的情況應該是在研究源代碼時(shí)，完全不知道它是在干什么，可能是來(lái)自你自己的項目，也可能是其他人的項目，但是問(wèn)題都一樣。這個(gè)時(shí)候，你必須確定是否值得花費更多的時(shí)間去尋找其它解決方案或者仔細剖析代碼，研究它到底是干什么的。

　　鑒于多年的PHP經(jīng)驗，我不得不說(shuō)Google真的是調試問(wèn)題的最好的小伙伴。這對于Objective-C，C++，Java和其他的主流語(yǔ)言的境況一定是相同的。錯誤提示信息對我們很有用，但是你必須記住不同的錯誤代碼代表什么意思。它讀起來(lái)更像是被翻譯過(guò)的計算機語(yǔ)言。幸好有這么多在線(xiàn)支持，讓我們確定這些錯誤信息代表的真正意思。

　　我們都知道想要退出時(shí)的那種極度沮喪的感覺(jué)，但是同時(shí)又覺(jué)得放棄不是正確的選擇。你很想繼續前進(jìn)，找出新的解決方案來(lái)。但是如果到最后還是浪費了一個(gè)小時(shí)，那該怎么辦？我對這種情況并不陌生，它會(huì )讓人特別沮喪。

　　如果涉及到最基本的前端代碼HTML/CSS/JS時(shí)，并不需要總是寫(xiě)注釋。但是如果是比較復雜的腳本和程序時(shí)，就需要寫(xiě)一些標準的注釋以便你幾個(gè)月，甚至幾年后來(lái)重溫這些代碼。有時(shí)候你會(huì )忘記給函數，參數，輸出格式以及其他重要的數據寫(xiě)注釋?zhuān)�這無(wú)疑會(huì )導致發(fā)生bug時(shí)你不得不調試整個(gè)腳本去尋求解決方案，感到非常困惑，到那個(gè)時(shí)候你會(huì )覺(jué)得要是有一些有用的注釋該多好啊。

或許構建程序時(shí)最讓人沮喪的是，明明剛才還好好的東西，沒(méi)有改過(guò)任何代碼，這會(huì )兒卻運行不起來(lái)了。我發(fā)誓這種情況絕對有發(fā)生，而且它沒(méi)有任何意義—也許其它程序運行的是緩存版本呢然后也有一些時(shí)候我們只更新了一丁點(diǎn)代碼，結果整個(gè)程序都崩潰并且完全停止運行。那就會(huì )回退到最新的備份版本，從那兒繼續吧。

幾乎我用過(guò)的所有的編程語(yǔ)言都要求每行結束時(shí)都要有結束符，但并不是所有的語(yǔ)言都這樣，不過(guò)C/C++系列語(yǔ)言絕對是這樣。當你忘記添加分號結束符時(shí)，這是多明顯的錯誤！但是解析器并不不理解，便拋出一個(gè)致命的錯誤。接下來(lái)就得再花費20分鐘時(shí)間去研究代碼，查找技術(shù)錯誤。最終發(fā)現只是少了一個(gè)分號。哈，這就是軟件調試的樂(lè )趣。

　　雇傭程序員的想法聽(tīng)起來(lái)很誘人，但顯然在經(jīng)濟上是不可行的。另外，如果你連自己的的錯誤都沒(méi)解決，你又怎么能從這些錯誤中學(xué)到東西呢？經(jīng)歷多次失敗，最后當你真正理解了編程的概念后，你會(huì )很有成就感。但有時(shí)候腦子里難免還是會(huì )閃過(guò)這種想法。

　　很多程序員對于瀏覽軟件和創(chuàng )業(yè)等社會(huì )新聞的偏愛(ài)選擇都是HackerNews首頁(yè)。它有大量的關(guān)于自由職業(yè)，時(shí)間管理，軟件開(kāi)發(fā)，創(chuàng )業(yè)發(fā)布和籌資資金等方面很棒的信息。盡管HN能夠模擬出通過(guò)自我教育更加高效的感覺(jué)，但其實(shí)是在浪費你的時(shí)間。每隔幾小時(shí)去快速瀏覽下新聞也沒(méi)那么糟糕。

　　最讓人沮喪的事情就是使用插件或者框架時(shí)，自帶的文檔很糟糕，你只好自己去深入閱讀源代碼。我更喜歡讓開(kāi)發(fā)人員花時(shí)間專(zhuān)門(mén)為項目設計一個(gè)文檔頁(yè)，對所有的參數和選項都給予解釋?zhuān)�有可能的�?huà)，給出一些示例代碼。但是很遺憾，這種情況幾乎不可能。所以最簡(jiǎn)單的辦法就是遠離那些附帶文檔很糟的工作，以免給自己帶來(lái)麻煩。

　　在編寫(xiě)和調試代碼的時(shí)候，我有時(shí)候會(huì )想不到備份。然而，數據備份能夠幫助我們回退到做出某個(gè)特定的改變之前的版本，這對一個(gè)即時(shí)的服務(wù)器環(huán)境是特別有用的，有些變化瞬間就會(huì )發(fā)生。切記在本地保留對網(wǎng)站文件和數據庫的拷貝，以備急需。你可能會(huì )覺(jué)得這樣太麻煩了，但是總比你重建一個(gè)SQL數據庫強多了。

　　如果花費了數小時(shí)后，仍然未找到一個(gè)解決辦法，很明顯你需要一個(gè)新的方案了。程序員總是想要先實(shí)現功能，然后再去設計和美化界面。先確定一個(gè)最快的，最準確的解決方案，并盡力去實(shí)現和完成，然后再去考慮美化界面的問(wèn)題就會(huì )很輕松了。

　　那些為編程語(yǔ)言提供依賴(lài)包和插件的團隊并不需要頻繁地發(fā)布產(chǎn)品。有時(shí)候從本地傳送文件到服務(wù)器的時(shí)候，更新PHP/Ruby/Python/SQL版本可能會(huì )解決一些調試問(wèn)題。除非你的版本實(shí)在太舊了，否則本地更新很少能夠幫助你修復源代碼中的bug，不過(guò)還是值得一試！

　　開(kāi)源的版本控制控制軟件Git在程序員中廣受歡迎。跟其他競爭對手相比，它提供了一條更簡(jiǎn)單的學(xué)習曲線(xiàn)，被應用在了許多在線(xiàn)倉庫像Github和Bitbucket中�？赡軐Τ鯇W(xué)者來(lái)說(shuō)，會(huì )有點(diǎn)難度，但是一旦你掌握了基本命令，你會(huì )發(fā)現使用GIt就是小菜一碟。它還讓版本控制更加清晰。

　　有時(shí)候嘗試了數小時(shí)的解決方案后，你可能需要將你的工作文件歸檔(或者刪掉它們)，重新開(kāi)始。這個(gè)決定的最大難點(diǎn)就是你會(huì )考慮到前面數小時(shí)的工作會(huì )毫無(wú)收獲。但是如果你保留之前的想法，項目卻毫無(wú)進(jìn)展時(shí)。重新開(kāi)始，才有可能讓項目順利完成。