張工是一名java程序員，有次，客戶反饋了一個緊急問題，張工一接到任務立馬開始排查bug，費了九牛二虎之力終于定位到問題所在，最后張工修改了5行代碼，bug解決了。

(資料圖片)

張工伸了一下懶腰，這時候財務妹子過來找張工確認上次報銷的事情，見張工懶洋洋的。

“不是吧，你今天又只改幾行代碼，你們做的軟件時不時出現這樣那樣的問題，工資還那么高。你看看我，我今天都做了兩張報表，連去趟茶水間倒杯開水都得一路小跑，真羨慕你們。

張工一時竟無言以對。

bug對于開發者來說并不陌生。改5行代碼，表面看似輕松，背后一直在超負荷運轉，所隱含的艱辛沒有經歷過是難以體會的。

作為一名軟件開發人員，在開發軟件時，雖然我們一直小心翼翼地編寫代碼，可做出來的軟件還是會出現這樣那樣的問題，為什么會這樣的，首先我們來看看什么是bug。

什么是Bug

有人對bug作了這樣形象的比喻：你家里的窗可以從外面打開，那叫漏洞。你家里的窗打不開，那叫bug。

但不得不承認，bug是必然存在的，好比人為什么會感冒。

我們來看bug是一般如何出現的。

開發人員和產品經理討論需求時，雙方需求溝通不到位

溝通本身是一個有損耗的過程，即使在溝通的過程中，產品經理針對需求講了很多，可到了實際開發的時候開發人員還是需要查看需求原型、需求文檔，重新梳理需求。這時候要是出現需求模糊的又沒有經過確認的，可能做出來的軟件會導致更多的業務邏輯問題和更多的bug。

這只是產生bug的其中一種，可以說，每一位開發人員背后都是踩著無數的bug一路走過來的。編碼是一個主觀的，完全由人主觀掌控的事情?？赡苣銜f，不是有軟件測試人員嗎？測試的工作不就是通過逆向思維來給程序員查缺補漏嗎？確實是的，但測試人員的介入只是降低了軟件出現問題的錯誤率，并不能徹底消除bug。其實每個每個系統都有bug，只是有些bug沒有被執行到而已。

既然bug無法避免，那么對于bug，我們是不是就束手無策，拿它沒有辦法呢？辦法還是有的。

首先我們最容易想到的一點是，增加軟件測試人員。多一人多一份力量，確實，但也因此增加了企業用人成本。

其次就是招聘一些經驗豐富的開發人員，這樣也可以避免產生一些低級bug，代碼邏輯嚴謹，系統穩定性強。這樣確實可以減少一些明顯bug，但bug還是無法避免。

最重要的是如何讓解決bug的這個過程更加快速。

解決bug主要做兩件事情：

作為一名軟件開發人員應該接觸不少bug，找bug是最耗時間的，特別是一些難以重現的bug。那么有沒有一些方法幫助我們定位bug呢，答案是肯定的。我們可以嘗試從下面幾點入手。

日志管理

系統日志記錄著我們認為容易出現問題的地方所產生的信息。但系統無時無刻都在運行著，必然會產生大量的日志信息，如何從這些信息中快速的找到關鍵信息，就是需要考慮的問題。我們可以給日志做一下歸類，定義不同的日志級別，在記錄的時候帶上前綴。譬如【info】、【warning】、【error】之類，對于error級別的信息自然是我們重視的，由于將其他級別的信息剔除掉，使得數據量減少，縮小排查的范圍，更加便于排查問題。

日志規范

團隊中，要是每個人都用自己喜歡的記錄日志的方式，沒有統一規范，那么從日志中找你需要的信息就變得很頭疼。所以，要做好打日志這個事情，統一一個規范很有必要，比如日志有時間，當前上下文的參數等。

注重編碼規范

類似這樣的經歷或許你也有過：

回頭看看自己一年前編寫的代碼，驚訝地發現，哇哈，如此不規范的代碼，是誰編寫的？確定是我寫的嗎？我能寫出這樣慘目忍睹的代碼？分分鐘鐘懷疑人生。

代碼規范的重要性我們都知道，但要真正做好，還需要我們在實踐中慢慢的累積，不斷修煉。那些看似無用的東西要經過我們慢慢地累積由量變達到質變的時候，相信你能體會到其價值所在。

養成良好的代碼規范不是為了別人，也不是為了公司，而是為了提高自己的編程修養，提高自己認識事物的能力。讓自己編寫的代碼可維護性更好、可重用性和可擴展性更強。

規范的代碼可以幫助快速調試程序，快速檢查找到問題所在，節省時間。養成一種好習慣，添加注釋。

有網友倜儻：程序員喜歡兩件事：

喜歡說別人程序不寫注釋；

喜歡自己在程序中不加注釋。

注釋的目的不是為了解釋代碼做什么——可以讀取代碼!注釋目的是為了解釋當你寫代碼的時候是如何思考的。

在編寫完代碼兩三個月后，可能我們已經不記得上述任何問題的答案，所以，寫下來很有必要的，能為我們后面解決bug提供了重要的線索。

重視溝通

職場里，有的開發人員在任務進展過程中不重視溝通，認為我只要最后把任務完成了就好了，結果往往需要項目負責人或上級主管問起來時才想起來匯報進展；更糟糕的情況是在開發過程中遇到了問題，沒有主動溝通，而是等到別人問起來了才說出來目前遇到的困難。

這樣會給別人造成極大的困擾和擔心：如果我沒有問，那么這個問題是不是就卡在這里？項目進度是不是就延期了。

職場上，對你的職場形象造成負面影響的其實并不是事情沒有按期達成，因為有時候確實有一些因素會導致事情無法正常完成，而危害最大的是你沒有及時溝通問題，造成問題的擱淺和發酵，最終造成的結果與預期不符；這會給團隊帶來不必要的麻煩：出現問題為什么不及早反饋溝通？

你遇到的問題，或者團隊中已經有人解決了。因此，我們需要意識到定期溝通的機制對于跟進效果是一個重要的指標；那么如何搭建一個好的溝通機制呢？在這里給大家推薦一個SMART模型。

編碼只是開發人員工作的一部分，團隊之間的溝通也不容忽視，溝通清楚了，需求理清了，避免一些業務邏輯因為沒有理解需求而產生bug。

責任編輯：Rex_08