程序員為什麼寫不出沒有bug的代碼

1. 如何提升程序員的代碼編寫能力

一、先列三個常見的開發場景：

1、拿到一個模塊詳細設計文檔，大部分程序員的通常做法就是開始搭建界面代碼，然後從第一個按鈕點擊事件或頁面Load事件開始寫第一行業務代碼。寫的差不多了，就運行一下，發現哪裡不是自己想的那樣，就改改，直到改到是自己預想的那樣。

2、做完了一個功能模塊或幾塊相關聯的功能模塊，輸入111asd，發現新建正常、保存正常，就提交給測試人員。測試員用測試用數據、測試場景用例來測試，發現有問題，就登記bug。對於嚴重的影響下一步測試的BUG，測試員就用內部IM通知這個開發人員。對於不影響繼續往下測試的BUG，測試員就登記下來，等程序員有空時處理。

3、程序員一般工作不希望大家打擾，所以開發起來就是開發。等手頭開發告一段落，就看看BUG庫。發現有與自己有關的BUG，就從第一個BUG開始看起。就開始通過IM和測試員掰扯起來（這不是個BUG啊、業務邏輯不是你想的那樣啊、我這里不能重現啊、你給的信息描述不清晰啊），於是IM幾來幾往，甚至跑過去當面交流一番，甚至會拉扯上產品經理一起討論，更甚者需要項目經理或產品經理發起一個會議來集體討論一下

這是不是很熟悉呢？這就是大部分程序員開發的三個步驟：寫代碼、自測、修復BUG。

二、說好的代碼設計、代碼測試呢？

代碼設計？那不是都有開發平台么，已經固化了啊。那不是維護舊功能做完善修改呢么，又不是寫新代碼，只能在現有代碼基礎上修改啊，你又不能大幅重構。

代碼測試？你丫需求討論期、產品設計期、設計評審期那麼長，都把研發項目時間佔光了，就留下2個星期讓我們寫代碼，我們哪裡有時間搞那麼深的測試。還想讓我們搞結對編程？還想讓我們搞測試驅動開發？

而且你看測試，什麼功能測試、集成測試、性能測試、安全測試、安裝部署測試、升級測試、遷移測試、UAT測試，一大堆測試，測試也需要很多時間。

一個項目，需求討論、產品范圍規劃與評審、產品設計與設計評審佔了一個半月，開發+自測就一個月，測試佔了一個半月，這就4個月了啊。

三、為啥程序員寫代碼總是寫寫測測？

剛才大家也都看到了，大部分程序員都是從界面代碼開始寫起，而且寫一寫，就運行一下看看。為什麼會是這種開發方式？

那是因為大部分程序員缺乏在腦子中的整體建模能力。只能做出來一點，真實的感覺一下，然後再往下。

有些是產品經理的上游就有問題，沒給出業務流程圖（因為產品經理也沒做過業務），也沒畫清楚產品功能操作流程圖。

為啥沒給出業務流程圖？因為產品經理不熟悉業務，另外，產品經理也沒有流程建模能力啊。為啥沒畫清楚產品功能操作流程圖啊？因為不會清晰表達流程啊。

很多產品經理、程序員，都缺乏分類、分層、相關、先後能力，更別說總結、洞察能力。

這是基本訓練，是一個做事頭腦清醒的人必備的技能，這不是一個程序員或產品經理或測試員的特定技能要求。

我經常看書就梳理書的脈絡，每看一本就寫一篇總結。我過去閑扯淡還梳理過水滸傳、紅樓夢的人物關系圖呢，其實就在事事上訓練自己的關聯性、層次性、洞察性。

我經常面試一個人時，我會問這樣的問題：「你把我剛才說的話復述一遍，另外你再回答一下我為什麼會這樣？」，其實，我就在看一個人的細心記憶、完整梳理、重現能力，我也在看一個人的梳理、總結、洞察能力。

我個人寫代碼就喜歡先理解業務流，然後理解數據表關系，然後理解產品功能操作流，大致對功能為何這樣設計、功能這樣操作會取什麼表、插入或更新哪些表，哪些表的狀態欄位是關鍵。

然後我寫代碼的時候，就根據我所理解的業務流、功能操作流、數據輸入輸出流，定義函數，定義函數的輸入與輸出。

然後，我會給函數的輸入值，賦上一些固定值，跑下來看看能否跑通這幾個關聯函數，看看還需要怎樣的新增函數，或者看看函數的輸入輸出參數是否滿足跑通。

剩下的事，就是我填肉寫詳細邏輯代碼了。

當然，大部分人沒我這樣的邏輯建模能力。怎麼閱讀理解也想像不出來，也沒法定義函數。畢竟有邏輯建模能力的程序員都很少，100個人里有10個，已經是求爺爺告奶奶好幸運了。

那怎麼辦呢？

我建議是分離分工配合，這就是現實中沒辦法的辦法。讓有邏輯建模能力的人來設計函數框架、來設計工具來設計代碼模板，然後讓沒有邏輯建模能力的人來填肉寫詳細邏輯代碼。

我們可以先從最緊要的模塊開始這么做。不緊要的模塊，還讓它放任自流，讓熟練手程序員繼續塗抹。

我曾經還讓有頭腦的程序員做榜樣，給大家分享他是怎麼規劃函數的，怎麼做維護性代碼的代碼結構改善的。但是發現效果並不佳，其他人並沒有因此能做代碼設計。可能邏輯建模能力是個人的基本素質，是從小到大訓練成型的，不是你一個大學已經幾年的人能夠短時間內可以訓練的。

所以啊，還是讓能走的人先走，讓從最緊要的模塊開始這么做。

不必擔心這樣做後，因為過去一件事被分工（一個做代碼框架一個填肉）成兩個人做了會降低工作效率。我們很多的工作效率低就是因為半瓶子醋搞出來的，來回反復修改。

真是應了劉德華在電影里說的那句話：說你又不聽，聽又聽不懂，聽懂了又不做，做又做不好，做不好還不服氣。

四、為什麼大部分程序員不做代碼測試或白盒測試或單元測試呢？

還是因為沒有代碼設計。因為沒有函數啊。所以，一個按鈕功能有多復雜，代碼就有多長。我見過2000行的函數，我也見過1000多行的存儲過程和視圖SQL。怎麼做白盒測試啊，這些代碼都粘在一起呢，要測，就得從頭到尾都得測。

所以啊，先學會設計函數，先寫好函數，這就求爺爺告奶奶了。很多開發了5年的熟練手程序員，可能都未必會寫函數。

函數的輸入輸出值就很有講究。很多人都寫死了，隨著版本迭代，發現過去定義的函數參數不夠用了，於是就新增了一個參數。然後，相關性異常就爆發了，其他關聯的地方忘改了，到底哪些有關聯，怎麼查啊，本系統沒有，沒准其他系統就調用你了，你根本不知道哪個神經人曾經COPY過你的代碼修吧修吧就改成了他的功能呢，而且裡面的很多代碼他看不懂也不敢刪，只要他實現的功能正常了他也不管了。於是，你改了你這個函數，他的系統就莫名出錯了。

所以，我一般會定義幾個對象來做參數。另外，我也很注重函數的日誌、函數的異常保護、異常拋出、異常返回。另外，我也很注重參數輸入值的合法性校驗。

所以啊，應該開發Leader們先制定函數編寫規范最佳實踐，輸入輸出參數怎麼定義比較好，函數的返回值如何定義比較好，函數的日誌記錄應該怎麼寫比較好，函數的異常保護、異常拋出、異常返回如何寫比較好。先教會一般程序員，先從會寫函數開始啊。

當然，你光有一份規范，程序員們還是不理解、不實際應用啊。所以，還得Leader們做好典型的代碼模板，裡面是符合函數規范的代碼框架，只有這樣，一般程序員們才會照貓畫虎適應了函數設計的編程習慣。

所以啊，我專門重新定義了leader的明確職責，其中第一個重要職責就是：負責工具/框架/模板/規范的制定，並且負責推廣且普及應用落地。

你不明確定義Leader的這個重要職責，你不對這個職責做明確的KPI考核，誰尿你啊。你以為好的工具/框架/模板/規范是靠人們的熱情、自發產生的么？我們還沒有那麼自覺高尚啊。

五、為什麼大部分程序員不寫注釋啊？

我經常說一句話，千萬別多寫注釋。為啥？

因為我們經常遇到的問題不是沒有注釋，而是更糟的是，注釋和事實代碼邏輯是不相符的。這就出現常見問題了：殘存下來的設計文檔是一個邏輯、注釋是一個邏輯說明、真實代碼邏輯又是一個，鍾表多了，你也不知道正確時間了。

所以啊，產品文檔、注釋、真實代碼，三者總是很難一致同步。我為了幾百人研發團隊能做到這個同步花了大量心血和辦法，但我最終也沒解決了這個問題，還把Leader們、總監們、我都搞的精疲力盡。

索性回歸到一切一切的本源，代碼，就是程序員的唯一產出，是最有效的產出。那麼，讓代碼寫的不用注釋也能看懂，咱得奔著這個目的走啊。

為啥看不懂，不就是義大利面條式代碼么，又長又互相交雜。

OK，我就規定了，每個函數不能超過50行。用這一個簡單規定和靜態代碼檢查插件，來逼迫大家嘗試著寫函數。有的函數屬於流程函數，是串起其他函數的，有的函數就是詳細實現函數，實現一個且唯一一個明確作用的。

有了流程函數和功能函數，而且每個函數不超過50行，這就比過去容易看懂了。

六、為什麼大部分程序員不抽象公共函數啊？

我經常說一句話：千萬別抽象公共函數啊。為啥？

因為大部分程序員缺乏抽象洞察能力。特別是有些積極熱情有餘、愛學習愛看書、半瓶子醋晃悠的二桿子，看了幾本UML、重構、設計模式、整潔代碼之道，就躍躍欲試了，還真敢給你抽象公共函數了。

一開始，他覺得80%相似，20%不相似，於是在公共函數裡面簡單寫幾個if..else做個區隔就可以。沒想到，越隨著版本迭代，這些功能漸漸越變越不一樣了，但是這個代碼已經幾經人手了，而且這是一個公共函數，誰也不知道牽扯多少，所以誰也不敢大改，發現問題了就加一個if..else判斷。

沒想到啊沒想到，這個本來當初公共的函數，現在變成了系統最大的毒瘤，最復雜的地方，誰也不敢動，除非實在萬不得已，手起刀落。

所以，我平時告誡程序員，純技術的、純通用的，你們可以嘗試搞搞抽象公共函數，對於業務的，你們還是簡單粗暴的根據Leader們做的代碼模板代碼框架，乖乖的復制、修改、填肉吧。

你們啊，先從做模板做代碼片段開始吧，咱們放到咱們內部代碼片段開源庫里，看誰的代碼片段被別人復制的多，說明你的代碼抽象設計能力越好了。那時候，我就大膽放心讓你撒丫子跑了。在沒有學會跑之前，給老子乖乖的復制、修改、填肉吧。

2. 當程序員寫不出代碼了，該怎麼辦

你已經對著電腦 n 個小時了。敲鍵盤正成為一種負擔，你在想，鍵盤是否就像西西弗斯推著的那塊巨石。

咖啡一杯接著一杯。不敢再喝了，因為搞不好要有副作用了，心跳加速，身體不由自主地顫抖，出冷汗，但還是無法產出任何代碼。

所有重新發現編程趣味的努力都徒勞無功，因為你的最後一點能量都用來驅逐大腦中正在攻城略地的話：

「我寫不出代碼了！」

總的來說，這個理念就是要你忘記手頭的問題，讓你的意識心靈沉浸到其他的事情中。此時，你的潛意識則開始連接要點，朝著頓悟的方向前行。

我們可以做些什麼以便於幫助大腦在發散思維的模式下工作呢？放輕松就好了：

• 散步（古代哲學家非常習慣於在走路時演講，因為他們意識到走路有助於思考）

• 清理辦公室或住所（完成後給自己一個獎勵）

• 與朋友約會，和杯咖啡，聊聊八卦（如果你過於關注問題的話，那麼建議和不能提供幫助的非編碼人員交談）

最後再說一句，如果你絞盡腦汁，卻仍然無法解決問題，那麼不妨先放一放。通過潛意識的運作，搞不好突破性的想法就會靈光乍現。

3. 程序員遇到百度不出來的bug都是怎麼解決的

筆者不同意下面網友的回答。程序員如果解決bug的水平停留在網路，那麼本質上只是一個「面向搜索引擎的代碼搬運工」，是不合格的程序員。

程序員對面bug，正確的「打開方式」是像福爾摩斯和柯南那樣，尋找線索、運用邏輯推理來縮小問題可能的根因范圍，最終精準定位。

常用的方法有：

1. 壞境上下文變換法

2. 工具調試法

3. 版本回溯對比法

4. 代碼審計法

……

沒有編程問題是stack overflow和Google解決不了的，假設你在編程中遇到了問題，你自己解決不了、你周圍的的人都解決不了的時候，我覺得stack overflow、Google是你最好、也是最後的幫手。

作為一個程序員，我覺得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等。

我是個程序員，職務是linux底層驅動工程師。平時的主要工作是調試驅動，但產品遇到諸如死機、重啟、不開機之類的問題時，也要參與查找原因。一部分問題，確實可以查看相關的log，然後網路這些log的關鍵字來解決；但更多的問題，牽扯的條件太多，並不是簡單的網路就能解決的。

觀察了周圍同事們的做法，我總結出以下幾種解決方法：

網路因為競價排名的原因，搜索出來的結果有很多廣告的成分，所以有時候要翻好幾頁才能看到一條相關的答案，有些甚至要翻幾十頁。

因為網路搜索使用的是SEO技術，即普通用戶可以通過優化網站內容來提升關鍵詞排名。

而這就會導致一個問題：你搜索關鍵詞後展現出來的結果是有人想要讓你看到的，並不是質量最好的。

也就是說，網路搜索結果被人為干預了。所以網路一直被網民所詬病。

但網路搜索不出結果，未必是網路的原因，也有可能是自己輸入的搜索詞不準確造成的。所以對於網路，我們要做到如下幾點:

除此之外，網路搜索還有點小技巧，粥左羅《萬字干貨，徹底講透搜索技巧，10倍提升你的搜索力（免費教程）》這篇文章寫得非常好，我整理幾點，僅供參考：

01 過濾目標內容

命令：「+」「-」

用法：通過「+」和「-」來對搜索結果進行過濾

比如在關鍵詞後加上「-推廣 -推廣鏈接」就可以排除搜索結果中包含相應字樣的鏈接。如果你發現廣告還沒有排除干凈，你也可以再加上「-廣告」通常就能徹底的消滅廣告。

02 搜索包含某關鍵詞的內容

命令：「intitle」

用法：通過「intitle」命令指定搜索結果中要包含的關鍵詞，注意「intitle」後邊連接的冒號是英文狀態下的。

03 搜索某一個格式的文件

命令：「filetype」

用法：通過「filetype」命令可以限制我們要搜索文件的類型，注意「filetype」後邊接的冒號也是英文狀態下的。

04 搜索特定時間范圍的內容

命令：「時間..時間」

用法：通過「時間..時間」命令可以限制我們要搜索的文件的時間，注意兩個時間的中間頓號沒有空格。

相對網路，谷歌、必應對於技術搜索，就相對准確許多，所以當你網路搜索不到時，嘗試下別的搜索引擎，說不定會有新發現。

現在程序員使用的機器語言，都是國外的，更准確的說，都是美國的。所以很多論壇、資料等，都是英文。如果你只會用中文來搜索，某些小眾的問題，當然搜不到啦。

所以，要學會使用英文關鍵字來搜索。

有時候甚至要去國外的一些論壇來搜索想要的答案，這就要求要有一定的英語閱讀能力，不能一看到英文帖就放棄。

有時候不管你如何搜索，都找不到自己想要的答案，該怎麼辦呢？這種情況下，就只能硬著頭皮嘗試自己解決了。

或者，尋求同事或朋友的幫助，尋求大腦風暴，說不定就會有思路。

如果有些問題是因為新器件帶來的，還可以找到器件供應商，讓他們安排技術支持幫忙查找原因。

除此之外，還可以把問題整理好，寫清發生的條件、復現步驟、測試方法、相關的LOG截圖等資料，去一些技術論壇發求助帖，尋找大牛的幫助。

做技術時間久了，發現有些問題確實無解，根本沒有辦法去解決它。

這時候，我一般會嘗試把它繞過，就是說，想辦法讓它無法復現，雖然問題還是存在，但是能把它掩蓋過去。

比如有些驅動在開機啟動時會載入不正常，那麼就讓它晚點啟動，或者手動載入。這也不失為一種解決問題的方法。

以上就是我的建立，希望對你有幫助。

首先作為一個程序員，一個優秀的程序員最最最重要的能力就是解決問題的能力。這里解決問題的能力當然就包含了解決 bug 能力了

畢竟，程序員這一生，可能會寫無數個 bug ，沒有說哪個程序員敢保證自己寫的程序沒有 bug 。 所以，寫了 bug ，遇到 bug 並不可怕，可怕的是你沒有解決 bug 的能力 。

作為一個程序員，解決 bug 的途徑有哪些呢？我們來一起聊一聊！

其實，每個程序員在學習編程的時候，都會使用編程工具，而現在的開發工具，其實功能都很強大。如果你自己合理利用編程工具，都了解和懂得開發工具的一些技巧，其實不僅僅能夠提高開發效率，而且還能夠幫助你解決很多編程中的實際問題。

debug 調試，大部分你常用的開發工具，都會有調試模式的，簡而言之，就是你編程的時候，遇到了不是自己所想的結果的時候，你可以使用 debug 模式，來一步一步的調試，在調試模式下一般每一步都會顯示所執行的結果，你可以看看在哪一步出錯了，執行的結果與你預想的結果不對，那麼你就能夠找到問題所在了。

還有就是，開發工具的控制台，都會提示出報錯信息的，現在的開發工具，都會直接告訴你哪一行，報了什麼錯。其實，很容易定位到錯誤的。你只需要在編程的過程中積累經驗，知道報什麼錯，用什麼方法來解決就行啦。

可是，提示的報錯信息，我不知道用什麼方法來解決的時候，該怎麼辦呢？這就是你需要積累的，也是問題中所描述的，就是通過搜索引擎來找答案。

不對，這里不應該是合理使用搜索引擎，應該是學會正確使用搜索引擎。比如：網路，你就不要用了，搜出一堆重復的信息，而且廣告也多。作為程序員，建議你使用谷歌搜索。

其實，你在編程中所遇到的幾乎所有的問題和 bug ，別人也同樣遇到過，因為不管是經驗豐富的老程序員，他技術再牛逼，也是初學者過來的，也都踩過你踩的坑。所以，互聯網是個好地方，裡麵包含了你想要的問題的答案。

你只要把報錯信息往搜索引擎上一放，回車一下，很多關於這個 bug 的答案就出來很多，你只需要找到跟你一樣的 bug ，就能找到答案了。

在這里必須提一下這個網站，所有的程序員有必要學會使用這個網站，其實，你編程中所遇到的問題，這個網站上幾乎都是由解答的。

Stack Overflow 可以說是最好的軟體程序類問答網站了，給軟體開發人員工作和學習提供了非常大的便利，以至於像小白，離了 Stack Overflow 簡直都不會寫程序了。

所以，建議大家一定要學會使用這個網站，對你編程肯定會有非常大的幫助的。

通過上面的方法，幾乎應該能夠解決到你所遇到的問題，但是，實在找不到答案的話，你可以問經驗比你豐富的老程序員，實在解決不了，那就換種方法吧！

網路，谷歌，debug，斷點調試，業務上的bug就需要問下同事或者產品。如果能知道大致范圍，哪一部分錯了，就換一種方法唄，一般都不會只有一種方法。

1.reload

2.restart

3.rewrite and then goto 2 or 4

4.reboot

5.rm -rf /

6.原諒我編不下去了[捂臉][捂臉][捂臉][捂臉][捂臉][捂臉][捂臉]

找bug跟醫生看病的思路是一樣的，要對症下葯。得先把問題的根源找到，找到根源以後問題就容易處理了。搜索引擎找不到的問題，說明這個問題不是一個常見的問題，具有獨特性，那麼從bug出現的路徑上一步一步去排查。必要時可以用排除法，盡可能的縮小排查范圍。另外，當軟體的業務邏輯比較繁多復雜的時候，一個結構清晰的架構能為你節省不少找bug的時間。還有，充分的單元測試能夠幫你減少出bug的機會。以上均為個人看法，歡迎討論！

一般程序員能碰到的bug無外乎其他上遊程序員寫庫時手抖留下些不匹配或者容易溢出的問題，搜一下差不多能解決問題。如果是自己寫的，那無非就是時序錯誤類型錯誤之類的，用break point一行行的調就好了。

再復雜點的bug就是程序員拿高薪的根本了，只可意會，不可言傳～

僅僅靠搜索引擎、其他網站那必然無法解決大量問題，因為很多問題是跟業務邏輯相關的，是沒有直接答案的。比如 游戲 開發有個界面一直無法顯示，這個問題就不是網路可以解決的。問題需要調試分析，這和破案非常像，但在開發過程中更有利的是問題有機會可以重現。破案是逆向工程，需要反推。解決代碼問題不僅僅可以反推，也可以通過閱讀代碼正向分析。下面說說如何debug一個業務邏輯問題。回到剛剛的例子，有個界面一直出不來，我們如何快速去定位：

1.思考這個問題發生的可能性。比如 游戲 內大量界面都是正常的，那麼可以對比正常界面代碼和異常界面代碼的區別，這是對比法。

2.假設創建正常界面和這個異常界面的邏輯代碼是一樣的，那麼問題就落到了這兩個界面內部，繼續在內部重復上面的對比法進行判斷，直到鎖定最終位置。

上面說的方法基本上可以杜絕卡在一個簡單問題上，這是擺脫新手的一個過程。選擇使用對比法或者其他方法的前提都是基於觀察和對項目的認識，所以，搜集「案發現場」是最關鍵的。

其他的問題，不屬於邏輯的，像其他網友說的那樣，有些通過到github、stackoverflow等地方解決的。這些問題也不是直接就去查找的，它通常也有個分析過程。比如你使用了一個庫，但是目前它不支持你的模塊。對於新手，就是直接網路或者google了。實際上這樣的問題也是有「案發現場」的。對於作者提供的api介面的統一性和便捷程度去推斷作者在相關支持模塊的位置以及命名以及拓展，再嘗試在文件夾中搜索。如果都找不到，再去Google上獲取更多的信息。重復推斷、分析，決定如何拓展或者繞過。

綜合上面的幾種問題，可以看到的是都離不開對現場的觀察和推理分析。這種能力也被稱為經驗。但是一般情況下你看不到它們這個分析過程，你能做的就是在實際環境中反復逼迫自己去思考，去訓練。這個推理的培養，不僅僅是對事情，也是對人。

我在入行 游戲 開發的前期，也是類似的情況。卡在不同種類的問題上，有些在簡單邏輯，有些在別人的代碼支持上。後面解決的問題多了，就會發現裡面共通的思維方式。常用的一些方法如下：

1.對比法，比較正常與異常代碼區別

2.二分查找法。分段注釋找問題，也會用在很多方面。比如最近版本突然出了一個奇怪bug，可以通過svn還原來定位。這個還原不是一個一個版本還原，而是用二分法去還原。

3.增加信息。在懷疑的位置或者過程添加日誌或者打斷點輔助自己更好的推理。

4.相似推理。比如一個引擎在api、性能使用程度上都非常友好，那麼它在別的地方也有可能相對表現比較好。這時候如果有個功能我們的實現需要很復雜才能完成，那麼就有可能是我們用錯了。相似推理不一定都能正確，但會提供一些幫助。

以上。

4. 程序員如何讓自己的程序少出BUG(轉)

軟體測試心得
，而且還經常寫一些工作上的事，現在感覺自己老了似的，開始轉型了，會選擇寫一些總結而不是瑣碎，也許這是我以後當領導的徵兆吧。
程序員是善於思考的一個職業，做過這行的都知道，寫一個程序的過程都要經過構思、設計、寫代碼、測試到最後運行這幾個步驟。慢慢地，這個習慣也被搬到了生活中，現在我才覺得，我平時做事這么的冷靜善思考原來是工作影響的原因。
象我一樣，大多程序員都有一個毛病，或者說一個習慣，自己編寫過的代碼都不願意測試，他們憑著自己的習慣，理論上完成了代碼的編寫就認為自己的工作結束了，剩下的工作應該交給測試人員了。但實際上來講，如果代碼存在BUG，造成軟體在運行期出錯，那麼測試人員和客戶肯定會發現這些BUG的，再等到測試人員或者客戶把BUG反饋回來的時候代價就已經很大了，不僅僅是時間的浪費，更重要的還有1、影響了客戶對產品以及公司的信任度，2、影響了程序員自己的聲譽，3、影響了代碼的可讀性以及質量，4、增加 了DEBUG的難度，5、對程序員的心理造成一定的影響。
首先，程序員應該克服自己身上的一些缺點，這是很重要的一點，因為每個程序員都有自己的編程習慣，而且每個程序員對自己剛剛完成的程序都會信心百倍的說「絕對沒問題」，實際上這種想法很正常，因為每段代碼都是通過程序員認真謹慎的思考和設計之後才寫出來的，在設計時已經排除了很多問題，所以程序員不會將自己認為不正確的判斷寫到程序里，但這僅僅是理論上的想法，但人哪有不反錯的時候。其實程序員在讀其他人寫的程序的時候，就會很謹慎，仔細找到程序上的錯誤，但對自己的代碼就很難這樣做，如果把這種謹慎應用到自己的代碼上來，BUG會減少到最少。軟體工程所說的各階段工作想必大家都清楚，前期的設計以及需求分析才是一個軟體工程的重點，這里也是花費時間最多的地方，當對要寫的程序有了一個清晰的輪廓之後再動手編寫代碼。
第二，剛剛提到的前期設計，是指在編寫代碼之前所作的工作，這要求程序員對系統的整個結構以及邏輯有很清楚的理解，這也要求對系統的需求做到位。我沒有寫過文檔，所以這里不談文檔了。思路清晰很重要，但每個人並不能將系統的整個設計思路都記在腦袋裡，那最好就寫下來，特別是一些復雜的邏輯結構關系還有復雜的演算法。
第三，代碼的編寫，要盡量減少拼寫的錯誤，嚴禁使用關鍵字作為變數來使用，要盡量做到代碼模塊化，並且保證其正確性和可重復使用性。因為是模塊組成的，寫過之後可以將每個模塊部分單獨測試，因為代碼量少了質量自然提高了。對順序執行要求很高的函數盡量不採用調用子函數的方法，讓程序按順序走吧。
第四：代碼檢查以及系統功能測試，這是保證代碼質量的最後一步了，我們可以寫一些代碼模塊或者小工具來進行測試工作，跟蹤變數值的變化，使用一些小技巧在這個階段都是必要的，這里和測試人員的測試不同之處在於：仍然讓程序員的注意力放在其自己的代碼范圍內，減小了排錯的難度。
按照如上步驟來走的話，那麼我想你的系統應該足夠健壯了。
把對待別人代碼的態度放到自己的代碼上來，也就是反復的Review自己的代碼檢查邏輯錯誤也是相當好的辦法。別把自己辛苦寫的代碼看的很值錢，在團隊中盡量與別人分享、Review代碼這是實際工作的經驗。
作為一個優秀的程序員要具備這些習慣，看自己的代碼就象對待自己的一樣，愛惜、呵護是必須的，同時也要象園丁一樣及時修剪多於的樹枝來讓自己的代碼走正確的道路。

5. 程序員為什麼要一直改bug 不能一次性寫好嗎

程序寫代碼就像造一座大樓，如果即便經過嚴格的設計論證，裝配高質量的部件，最後還有系統性地驗收，讓你去造這么一座大樓，你能保證不管是窗戶安沒安好，還是地基挖淺了挖深了，還是牆皮脫落，都一個問題沒有？
回想早年的小程序，執行某一個具體的任務，明確的輸入輸出，一般是不會有bug的。
但現在的軟體開發，早就已經不是一個人在戰鬥了，大部分的工程，開發規模5人左右居多，另外稍大的軟體工程動輒幾十人，更有甚者幾百人的團隊規模並行作業。你試想一下，要保證這么多人的產出都符合設計要求，勢必需要合適的開發流程，需要更多的項目管理的技巧和方法。這就對個人以及團隊的提出了非常高的要求了。
軟體工程的方法論中，要求軟體開發者盡可能多地在軟體測試階段發現bug，而不是交付之後。
但是樓主說的能不能讓軟體開發出來沒有bug，我覺得把下面這幾個事情做好，還是有可能的。
1、花盡可能多的時間，和客戶溝通軟體需求，了解每一項需求的用意。
2、確保軟體需求不能隨意變動，因為很多情況下一個需求的變化，程序會帶來很多問題，有可能連底層結構都需要跟著一起變動。頻繁的需求變動，加上開發周期和成本的約束，帶來的結果就是軟體質量的不可控。
3、確保軟體測試質量，完成全覆蓋測試，設計系統需要的全部用例並保證全部通過。
總結下，軟體項目在實際開發過程中風險點還是很多的，通過合理的控制，可以降低和減少bug。但是軟體本身是為人的需求而生，只要需求在變化，軟體是永遠都需要跟著去維護和更新的，所以只要有不可控的因素（需求分析，系統設計，系統詳細設計，編碼，單元測試，集成測試，系統測試，驗收等）任何一個環節任何一個人產生問題，反映到最後的軟體產品上就是一個bug。
另外Bug分很多類，一類是對用戶來說不能正常使用，能被用戶感知到的錯誤。一類是用戶能正常使用，但是有各種異常的錯誤。一類是使用沒有任何問題，但是不符合產品預期的問題。其他應該還有很多，這里我們一一討論。

對用戶來說不能正常使用，能被用戶感知到的錯誤。
其中一種情況是程序員和測試人員的問題，所有功能在上線前，工程師和QA人員應該測試，回歸完功能。能被用戶感知到使用流程有問題的話，一定是相關人員能力或者線上意識某一方面欠缺，也是最不能容忍的。
另外一種情況是黑天鵝事件，什麼網線被挖斷，機房被炸，伺服器爆炸什麼的。。。。。。 ，這個說實話，出了在軟體架構上做冗餘，目前沒有什麼特別好的辦法。

2. 用戶能正常使用，但是在用戶看不到的地方有各種異常的。
一個功能模塊幾乎不可能是獨立的，它必然牽扯到其他模塊。對於你所依賴的模塊，你沒辦法保證這些模塊是100%可用的。這個時候可能雖然有錯誤，但是只要不影響主要流程，我們依然可以正常使用。但這個時候對於外部依賴的異常處理，很考驗工程師的能力。
舉個例子，有可能你看到的點贊數比你實際收到的點贊數少。這個是由於點贊統計在什麼時候失敗了一次，某些用戶可能認為這個是bug，但是其他可能不會在意（當你有10001贊的時候，你在意少了1個么？）
3. 使用沒有任何問題，但是不符合產品預期
這個更多的是研發和產品經理對於需求理解的不一致。因為文字是有二義性的，況且人和人對相同文本的理解本來就可能出現偏差，這就導致了需求理解的不一致，最終導致了線上產品不符合預期。對於內部人員來說，這個也算BUG。
說了那麼多，最主要的核心在於實現功能的是人。人不像機器，不可能不犯錯；同樣的，不可能存在沒有bug的程序，像大家使用的windows，窮盡無數優秀的工程師，給予用戶優秀的桌面體驗的同時，也有你可能完全看不到的數千個bug。想要完全避免幾乎是不可能的。所有也不存在一次性就寫好的情況，鬼知道產品經理什麼時候改需求呢~

6. 程序員為什麼要一直改bug，不能一次性寫好嗎

軟體可能在使用過程中沒有任何問題，但不符合產品的預期下圖源自「How projects really work？」，很形象的突出了客戶需要的產品和最終得到的產品不一致。

所以軟體想要變得成熟，Bug收集和處理機制是非常有必要的，比如：會影響客戶使用的優先順序高的Bug要優先修復。Bug是軟體的影子，也是程序員的噩夢實際上不能存在沒有bug的軟體，Bug和軟體如影隨形。就像我們使用的Windows，窮盡無數優秀的軟體工程師來設計給用戶優秀的桌面體驗，但也有各種層出不窮的bug。

程序員對Bug有多愛就有多恨，Bug無處不在，即使再牛逼的程序員也逃脫不了Bug的魔掌。想要完全避免Bug幾乎是不可能的，所以也不在一次性就寫好的程序。以上個人淺見，歡迎批評指正。認同我的看法，請點個贊再走，感謝！喜歡我的，請關注我，再次感謝！

7. 程序員為什麼要一直改bug不能一次性寫好嗎

作為一名程序員，我也總是在調試，Bug總是防不甚防的出現，這個過程真是有趣又痛苦，最後我覺得習慣就好，一次性寫出完美代碼是每個程序員不可實現的夢想。

沒有哪個程序員可以寫出完美的代碼，即使高能又偉大的公司也做不到這一點，想想看你的手機軟體是不是經常提醒你該更新了，連微軟都在三天兩頭的讓你打補丁，不是嗎？

8. 資深程序員可以避免敲代碼時出現bug嗎

程序員遇到bug是在正常不過的事情了，就算非常資深的程序員也無可避免bug的存在，一般來說，除非你寫一輩子 Hello World。
不過世界上的確存在一些鳳毛麟角天才的程序員，他們差不多能做到這一點。接到任務之後，思考，冥想，在筆記本上畫出數據結構或某個演算法片段，腹稿打的差不多了就開 始編程，用 Vim、Emacs 或 IDE 工具，大部分時候能夠一氣呵成，然後構建代碼，構造測試數據，運行程序，在反復調試中修復幾個編程過程中沒有考慮到的問題，就可以提交到代碼庫了。
他們的 代碼交給測試和其他開發者，少有人能挑出 bug，因為他們對代碼有敏銳的感覺，能夠在別人忽略的地方發現代碼的壞味道，並給出巧妙而優雅的解決方案。
他們是天生的代碼創造者，這樣的人往往效率高 而且少有錯誤，以至於會被一些平庸的團隊忽略，因為技術領導總是會下意識的去關注那些最容易出事的環節，但這些人才是團隊真正的脊樑，不是那些四處救火者。

9. 為什麼總有無數的Bug困擾著程序員 – 碼農網

下面就是為什麼我們的軟體之所以依然充滿漏洞的5大原因：
1.人的天性
大多數——當然不是全部——軟體bug源於我們自己犯的錯誤。雖然有些是因為軟體編碼工具和編譯器發生了意外，但是大部分的錯誤得歸咎於我們自己。
無論我們受到的SDL培訓和安全工具有多麼強大，只要我們還是人，我們就會犯錯。如果你想問為什麼電腦軟體會有這么多的漏洞，歸根到底是因為，人的天性就是容易犯錯。
也就是說，我們在減少人為錯誤方面做得還不夠。有很多程序員因為沒有受到足夠的SDL培訓（有的甚至乾脆就沒有培訓），所以根本就沒有安全編程的理念。有時候我特別奇怪：有那麼多的程序員以寫安全軟體為生，卻居然不懂如何安全地編程。別不信，我敢打賭，你正在運行的銀行安全軟體中的bug不會比它能提供的保護措施少，搞不好甚至更多。
但是即使是那些經過嚴格訓練的程序員還是不可避免出現bug。舉個例子，前不久有個自鳴得意的傢伙發明的使用HTML標記欄位確定顏色的緩沖區在瀏覽器中溢出了。不像以前還要輸入FFFFFh之類的東西，黑客甚至可以直接執行顏色域的代碼，從而導致瀏覽器過度消耗資源、緩沖區溢出。看到沒有，這就是漏洞！而且很少會有人能預料到這種情況。
2.不斷增加的軟體復雜性
就其本質而言，軟體越復雜，就意味著代碼行數越多。只要你在編程，那麼即使你有多擅長寫代碼，也一定會有錯誤和bug出現。有人曾說，如果你能做到每50行代碼中只出現一個錯誤，那你就已經做得相當好了。大多數程序員差不多每隔5至15行就會犯錯。想像一下，這么說吧，一般性的Linux內核擁有超過1500萬行的代碼，有多少bug你自己算吧！
即使沒有編碼錯誤，互聯網時代應用程序的整體互動性也是漏洞被攻擊的途徑。大多數程序員不得不和其他API協作，保存和檢索文件，在多種設備上正常工作。所有這些過程都會增加被成功擊破的概率。
而要防守的話，則需要寫更多的代碼，因為得抵禦各種不同的攻擊渠道。這么說吧，如果有一個只有30條匯編語言指令的惡意程序，那麼針對相應的防守，你可能至少得寫50000條匯編語言指令！
3.Fuzzers也是人寫出來的
新近冒出來的Fuzzers軟體主要用於掃描軟體漏洞。Fuzzers——以及其他用於尋找編碼錯誤和漏洞的任何程序——都是人寫出來的，還是這句話，是人就會犯錯誤。例如Fuzzers是不會發現顏色屬性的緩沖區溢出這種情況的，這是因為我們在寫Fuzzers的時候沒有考慮這一方面。不過當我們意識到這一點並對Fuzzers進行更新之後，就能做到去查找各種類似的緩沖區溢出條件的欄位。簡而言之，我們要Fuzzers做什麼，它才會去做什麼。
4.缺乏對供應商的問責
許多安全專家抱怨，只要我們不能找到證據起訴供應商的軟體缺陷，我們就永遠不會變得更安全。我贊同這一點，增加對供應商的問責有助於降低安全風險，但是同時卻有可能會減緩進度。不過如果軟體公司比現在更能擔當起責任來，那麼我想我們能在手機上、電腦上能自由自在沖浪的感覺會更爽。
但是成功源於功能和速度，而非安全。社會現狀決定了我們必須犧牲一部分安全和保障去換取新鮮感。這不一定是壞事——因為能讓我們成功得更快。但是這樣一來我們就不得不承擔這樣做的後果。不過到目前為止，我們還是心甘情願為了添加更酷的新鮮玩意兒而面對更多的風險。

5.缺乏對黑客的問責
現實是上面沒有一條能很快解決。但是軟體出現漏洞就其本身而言，真不是什麼大問題。說它脆弱是因為這些軟體在面對惡意攻擊的時候毫無抵擋之力。除非我們能制止黑客的猖獗行徑，否則惡意軟體將會一直困擾著我們。
但是我依然深信，將來有一天我們的互聯網會有更好的普遍標准出台，我們能在現實中及時地將那些損害大家利益的傢伙繩之以法。不過在此之前，我們還是得不斷地寫補丁，在黑客的狂轟濫炸下苟延殘喘。