你的代碼出bug了，程序員聽到這個時的表現太真實了

程序員是一份頗有挑戰的工做,沒有人能作到完美,寫錯代碼也是常有的事。

那麼,當程序員BUG時，會是什麼情景呢？

A.別人寫的代碼有bug

這個大撒比寫出這麼個爛代碼，幸好有哥這樣神同樣的存在才發現，哥真是救世主。

B.本身寫的代碼有bug

1.運行好久

<1>別人發現

這個程序運行好久了是否是真有bug啊，是否是你弄錯了啊，能夠重現麼，什麼？能夠重現，有尼瑪問題也不大，要不用戶早投訴了，瞧你那惶恐不安的樣子，真想吐你一臉狗屎。

<2>本身發現

這個bug隱藏的很深啊，還好哥犀利犀利，沒有被領導發現，今晚加個菜。

2.新上線程序

<1>別人發現

這個程序剛上線還處於調試階段，有bug很正常，誰的程序沒bug，連操做系統都有bug。

<2>本身發現

哥就是犀利，本身開發本身測試，看測試那幫撒比什麼也不會幹，這麼明顯的bug都測不出來，真是一羣廢物。

C.接下來進入修改BUG的程序

一、「是刪除它仍是修改它呢？好糾結 ！」

二、網上必定有解決辦法。

三、是誰動了個人代碼？

四、徹底不知道這些代碼是神馬東東。

五、哦，爲何我都沒寫註釋呢？

六、算了，廢了他，我仍是從頭開始吧！

其實不少公司將BUG量做爲評估一個程序員晉升的重要參考指標，由於BUG量的多少能直接反映你開發的代碼的質量，也直接影響版本發佈的時間週期。

因此，編寫高質量的代碼對程序員在職業道路上的晉升起到不可忽視的做用。

反觀身邊的同行會發現這樣一個結論，越是程序大牛，其開發的代碼的BUG量越少。

BUG經常困擾着程序員，BUG若是在開發和測試階段沒有被發現，將會隨着產品發佈，在生產環節被觸發，有時候會帶來很是嚴重的後果。

爲了本身考慮，節省本身 DEBUG 的時間，程序員們應該讓本身的程序儘可能沒有 BUG 。

那麼，程序員該如何儘可能減小程序中的BUG？

程序員自身能夠在程序生成的每一個階段作這些工做：仔細的設計、編寫代碼時、單元測試(重要)、功能測試。

1. 仔細的設計

這個的仔細是說在程序員編寫代碼以前，其必須對代碼的整個結構以及邏輯結構有明確的清晰的瞭解，只有這個時候才能夠去寫代碼。

這裏沒有談到文檔，但必定要清晰的思路，清晰的思路不是每一個人均可以在腦殼中直接造成的，不少人都是普通人，沒有辦法在腦殼瓜中把全部問題都想清楚，那麼就記下來，特別對於複雜的邏輯。

2. 編寫代碼

對於沒有把握的代碼，例如：新設計的算法，最好保證其正確性。能夠單獨將這部分測試，這可讓代碼模塊化的同時又保證了代碼的正確性。

一句話：少許的代碼保證質量仍是比較簡單的。

3. 單元測試

單元測試的重要性不在贅敘了，如今也有許多工具能夠幫助程序員並減小工做量。

4. 功能測試

程序員保證本身代碼質量的最後一關;爲了作這樣的工做咱們可能必須寫一些代碼來測試，甚至是測試工做。使用大量的 CASE 來測試，以及錯誤的 CASE 。

這裏和測試人員的測試不一樣之處在於：仍然讓程序員的注意力放在其本身的代碼範圍內，減少了排錯的難度。

得程招聘，千萬程序員求職新選擇！本文由得程撰寫。