修正一個bug的風險到底有多大？或許，你會說，這要看bug是發生在什么地方，的確，UI層的樣式問題、后臺邏輯調用層的錯誤、數據訪問層的異常、數據庫級別函數或存儲過程的修改……一個bug產生的影響可能微乎其微，當然也可能會影響廣泛，甚至影響到程序架構！
撇開比較極端的情況，今天想要說的是我們日常工作中遭遇頻率最高的一類bug：主要發生在UI層、數據邏輯層的常見bug。對于這種bug，我們又有過多少次因忽略其上下文關聯，或者沒有添加完整的條件驗證和條件處理，導致程序異常，不得不再次修改的經歷呢？
這里并不是要批判我們的“粗心大意”，只是要說明這樣一個事實：作為一名開發人員，在處理一個bug的時候，很容易因過于關注bug的細節而“忽視”與其關聯的上下文；或在沒有完全理解原代碼工作完整工作機制的情況下就動手修改bug，導致問題層出不窮……相對前者來說，后者的影響更加的廣泛，所以，一般情況下，團隊Leader都會指派對某功能模塊最為熟悉的人員來處理相關bug，這其實就是一種最為常見的減少風險的方法。
根據自己在類似問題上多次碰壁經驗來看，最為成熟和有效的方法，其實就是從完善我們自己修改bug的流程開始的！為什么這么說呢？打個比方，老婆昨天去醫院拔牙，后來把醫生的單據給我看，發現醫生也是在按照成熟的流程進行作業的，可見一個相對成熟的流程對于我們處理問題是多么地重要！
回到咱們的主題，處理bug時，我們是不是按照一個自己認為合理的流程進行的呢？我想每個人可能有屬于自己的流程，這里僅僅是自己的一點兒看法，僅供參考：
（1）打開bug列表，你可能使用的是bug tracker或其他bug跟蹤工具，這個無所謂。查找你負責的bug項。
（2）逐條地對bug進行處理，我比較傾向于將當前處理的bug再拷貝一份到自己的bug list文檔中，我會添加一些個人的備注，例如，bug的原因，目前的進展，是否需要進行再次驗證或與產品經理進行討論等等，主要是方便自己對bug進行完整的跟蹤。
（3）仔細閱讀bug標題和詳細內容明細，一般情況下，帶注釋的截圖是非常直觀的，個人比較喜歡。如果有疑問的話，需要馬上找提交bug的測試人員進行確認，并注意記錄發生bug時的關鍵數據。
（4）在自己的開發機器上重現bug，起初應該盡可能地按照測試人員提供的關鍵步驟進行操作，以便迅速重現，如果經過簡單分析就可以推斷問題的根源的話，可以常識性地進行一些bug驗證。
（5）開啟調試功能，重現bug并跟蹤代碼，找出問題的原因，一般情況下，如果是因對象不存在或賦值錯誤導致的異常，我們可以直接修正，如果涉及到數據異常的情況，可能我們就需要對產生bug的代碼捎帶其上下文進行一下排查，因為很有可能是因為數據提供方或者處理方導致了最終的異常。
（6）確定問題根源，并進行修改后，我們需要進行自我驗證！這一步是非常關鍵的，以至于大家可能很容易忽視！自己也是常常因為覺得一個bug并不難，于是順手就改了，應該不會有啥問題，然后就check in了，后來的情況大家想必也猜到了，bug被測試打了回來，這還沒什么，如果要是需要直接提交給實施或者客戶的程序，那后果可就不堪設想啦！這里還有一點需要注意，我們不僅要按照原bug關鍵步驟進行重復測試，同時還要對相關的流程進行排查性測試，因為我們的修改很有可能影響到周邊相關的功能，而當我們對此功能模塊不是太熟悉的時候，這種風險尤其大，必須要格外留意。
（7）再經過上面一步非常重要的自我驗證后，我們就可以提交我們的代碼了，這里同樣有一個很容易被忽略的細節：填寫bug備注。因為這是別人了解你此次提交更改的唯一途徑，如果馬馬虎虎，或者是干脆不寫的話，那么你的修改出現問題，光追查原因就要浪費很多的時間，如果那哥們如果已經遠走高飛以后，那就更加的棘手了！為別人著想也就是為自己著想。
（8）及時向相關測試人員提供你此次修改的一些情況，尤其是如果涉及范圍較大，需要進行排查性驗證的時候，一定要向測試人員交待清楚，因為盡管我們做了測試，但依舊有可能有所遺漏。
（9）定期查看bug列表，跟蹤自己負責的bug，并及時更新自己的bug list文檔。
以上就是自己在處理bug時采取的一般流程，自從自己將這個流程形成文字后，遇到的因bug修改不完全導致的問題明顯減少了，因為這些問題都在自己進行自我測試及排他驗證的時候發現了，并在提交之前都進行了處理。以前自己因為這樣的情況經常發生，經常會感到非常氣餒，也懷疑過自己的能力啥的，后來經過一個做測試的哥們提醒才豁然開朗，每個人都會遇到“焦點關注”的問題，因為過于關注于技術細節而忽視前后邏輯關聯，這也是造成這個問題的主因。所以說，自己要努力通過完善合理的流程來減少其造成的后果，而不是盲目地進行否認~
希望能對你有所幫助~