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