Celiaki
沒有編程問題是stack overflow和Google解決不了的，假設你在編程中遇到了問題，你自己解決不了、你周圍的的人都解決不了的時候，我覺得stack overflow、Google是你最好、也是最後的幫手。
沒有什麼問題是Google、stack overflow解決不了的
作為一個程序員，我覺得Google、stack overflow是你必須要學會使用的兩個工具，這兩個工具本身並沒有使用門檻，只不過因為一些眾所周知的原因，很多人不能使用Google和stack overflow這兩款工具。
Google主要還是方便，而且很多編程問題都需要用到英文搜索，當然現在百度在專業能力上也提升明顯，不過跟Google也還是有比較大的差距，因此我還是強烈建議要學會使用Google，這會幫你在工作、學習上事半功倍。假設Google確實因為某些原因沒辦法很好的使用，我也建議你至少要會使用Bing搜索。
現在可以說stack overflow上沒有你找不到的問題了，從IDE環境安裝問題，到各類編程語言問題。算法問題，數據結構問題，調試，重構等等，幾乎這裡就沒有你找不到的答案，可以說在stack overflow上你可以找到任何解決方案，並且上面的回答者基本上都是非常有經驗，而且都是實際中遇到的問題分享出來的，這個工具一定要會使用。同理，除了stack overflow這個專業的垂直程序員問答社區，你也可以使用Quora這個綜合問答社區，這上面也能找到很多問題的答案。
程序員常用工具集介紹
一些比較優秀的文本編輯器：Emacs/Vim，Visual Studio Code，Sublime Text，Atom，Ultraedit，Hbuilder等。
一些比較非常出色的IDE集成開發環境：visual studio，IntelliJ IDEA，PhpStorm，Haskell for Mac ，eclipse，WebStorm，GoLand，CLion，Android Studio，Xcode，QT等。
macOS平臺比較好的第三方包管理工具：Fink，Macports，Homebrew等。
一些比較好的終端工具：Zoc7，iTerm2，Cmder，terminus，hyper等。
一些比較好的筆記軟件、markdown工具、效率工具：Evernote，有道雲筆記，為知筆記，Ulysses，MWeb，FileZilla，Snipaste，Kantu等。
虛擬機軟件、容器軟件：Parallels Desktop，VMWare Fusion，Virtual Box，Docker等。
EmacserVimer
筆者不同意下面網友的回答。程序員如果解決bug的水平停留在百度，那麼本質上只是一個“面向搜索引擎的代碼搬運工”，是不合格的程序員。
程序員對面bug，正確的“打開方式”是像福爾摩斯和柯南那樣，尋找線索、運用邏輯推理來縮小問題可能的根因範圍，最終精準定位。
常用的方法有：
1. 壞境上下文變換法
2. 工具調試法
3. 版本回溯對比法
4. 代碼審計法
……
周林ZhouLin
僅僅靠搜索引擎、其他網站那必然無法解決大量問題，因為很多問題是跟業務邏輯相關的，是沒有直接答案的。比如遊戲開發有個界面一直無法顯示，這個問題就不是百度可以解決的。問題需要調試分析，這和破案非常像，但在開發過程中更有利的是問題有機會可以重現。破案是逆向工程，需要反推。解決代碼問題不僅僅可以反推，也可以通過閱讀代碼正向分析。下面說說如何debug一個業務邏輯問題。回到剛剛的例子，有個界面一直出不來，我們如何快速去定位：
1.思考這個問題發生的可能性。比如遊戲內大量界面都是正常的，那麼可以對比正常界面代碼和異常界面代碼的區別，這是對比法。
2.假設創建正常界面和這個異常界面的邏輯代碼是一樣的，那麼問題就落到了這兩個界面內部，繼續在內部重複上面的對比法進行判斷，直到鎖定最終位置。
上面說的方法基本上可以杜絕卡在一個簡單問題上，這是擺脫新手的一個過程。選擇使用對比法或者其他方法的前提都是基於觀察和對項目的認識，所以，蒐集“案發現場”是最關鍵的。
其他的問題，不屬於邏輯的，像其他網友說的那樣，有些通過到github、stackoverflow等地方解決的。這些問題也不是直接就去查找的，它通常也有個分析過程。比如你使用了一個庫，但是目前它不支持你的模塊。對於新手，就是直接百度或者google了。實際上這樣的問題也是有“案發現場”的。對於作者提供的api接口的統一性和便捷程度去推斷作者在相關支持模塊的位置以及命名以及拓展，再嘗試在文件夾中搜索。如果都找不到，再去Google上獲取更多的信息。重複推斷、分析，決定如何拓展或者繞過。
綜合上面的幾種問題，可以看到的是都離不開對現場的觀察和推理分析。這種能力也被稱為經驗。但是一般情況下你看不到它們這個分析過程，你能做的就是在實際環境中反覆逼迫自己去思考，去訓練。這個推理的培養，不僅僅是對事情，也是對人。
我在入行遊戲開發的前期，也是類似的情況。卡在不同種類的問題上，有些在簡單邏輯，有些在別人的代碼支持上。後面解決的問題多了，就會發現裡面共通的思維方式。常用的一些方法如下：
1.對比法，比較正常與異常代碼區別
2.二分查找法。分段註釋找問題，也會用在很多方面。比如最近版本突然出了一個奇怪bug，可以通過svn還原來定位。這個還原不是一個一個版本還原，而是用二分法去還原。
3.增加信息。在懷疑的位置或者過程添加日誌或者打斷點輔助自己更好的推理。
4.相似推理。比如一個引擎在api、性能使用程度上都非常友好，那麼它在別的地方也有可能相對錶現比較好。這時候如果有個功能我們的實現需要很複雜才能完成，那麼就有可能是我們用錯了。相似推理不一定都能正確，但會提供一些幫助。
以上。
幽默抓搞笑
1、如果是baidu的話，搜國外的熱門技術就不太好用了——建議google。google搜國內的沒問題，但baidu搜國外的不行，何不一步到位就google呢？
2、問題太寬泛或太不好描述。如：沒有錯誤碼，或者很模糊的解釋 ——多猜想可能性，逐漸收斂搜索範圍。
3、ABC的問題。可能人家的說明文檔的第一節就已經寫得很明白了，你沒仔細看——靜心想想，自己是不是把問題搞複雜了，重新讀讀基本說明。這類問題和小夥伴討論一下很容易有答案。
4、自己的程序或業務邏輯，沒有特定的方向和框架性，無法搜，比如你的遞歸算法為什麼就是有問題——不睡覺也要搞出來呀，是不？。。。當然，已經盡力了就找高手幫你審審吧。
5、搞錯了方向，比如你搜的是一輛（柴油）車是加多少號的汽油比較好，會怎樣。也許這個比喻很愚蠢，但現實中我們難免認識不足——需要足夠的資料甚至源碼，最終會意識到，原來框架沒有提供這個功能。
研究的技術目前受眾太少——開源的下載源碼進行調試。商用的請求售後。
6、系統中軟件衝突。例如之前魔獸和搜狗五筆衝突了，為知筆記有個版本用搜狗五筆輸入就退出，以前我們的程序和客戶電腦上一個不知道什麼名字的軟件衝突過。
這個，算bug麼？不管算不算都會找到你頭上，對吧——這種情況一般做對比法，然後排除法。
搜索引擎能幫你解決什麼bug？環境安裝問題，特定框架特定錯誤，API使用錯誤？很多時候，它只是給你提供一些出錯的可能性，給個方向讓你逐個排查而已。大多有難度的bug，還得靠我們自己的邏輯思維, 紮實的調試技巧，經驗，背景知識，甚至人品等
小超人影視廳
1.reload
2.restart
3.rewrite and then goto 2 or 4
4.reboot
5.rm -rf /
6.原諒我編不下去了[捂臉][捂臉][捂臉][捂臉][捂臉][捂臉][捂臉]
宛丘的故事
網上的bug基本都是自己不小心哪裡寫錯了，本機斷點一步一步調式。基本可以解決。
王小販丶
看提示單步調試一層層剝開去。一般都是傳參很容易早出來。如果環境配置問題這個就慢慢磨唄看提示。實在不行放出來大家看看。實際工作中bug也不一定要立刻解決，自己分析先放鬆總會解決的
樂趣生活手心向上
找bug跟醫生看病的思路是一樣的，要對症下藥。得先把問題的根源找到，找到根源以後問題就容易處理了。搜索引擎找不到的問題，說明這個問題不是一個常見的問題，具有獨特性，那麼從bug出現的路徑上一步一步去排查。必要時可以用排除法，儘可能的縮小排查範圍。另外，當軟件的業務邏輯比較繁多複雜的時候，一個結構清晰的架構能為你節省不少找bug的時間。還有，充分的單元測試能夠幫你減少出bug的機會。以上均為個人看法，歡迎討論！
文藝範小影子
1.可以採用排除法，一步步還原改動的代碼，直的不報錯為止，這樣可查出問題所在;
2.把你報錯的異常放在論壇上面發貼求教，相關的論壇有csdn,iteye等等;
3.打斷點調試，一步步調式哪裡代碼出現問題，具體問題具體分析;如果是jar包裡面出現的問題，查看是不是版本問題導制的;
4.如果查看代碼沒有問題，但是程序依然報錯，可看看是不是做的一些特殊操作比如讀取文件流或循環等，是不是內存溢出等，這個可能是代碼質量問題，需要優化;
希望對你有幫助！~
衛Java
一般程序員能碰到的bug無外乎其他上游程序員寫庫時手抖留下些不匹配或者容易溢出的問題，搜一下差不多能解決問題。如果是自己寫的，那無非就是時序錯誤類型錯誤之類的，用break point一行行的調就好了。
再複雜點的bug就是程序員拿高薪的根本了，只可意會，不可言傳～
