<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          這么簡單的bug,你改了2天?

          共 2553字,需瀏覽 6分鐘

           ·

          2021-06-18 12:37

           這里是Z哥的個人公眾號

          每周五11:45 按時送達

          當(dāng)然了,也會時不時加個餐~

          我的第「196」篇原創(chuàng)敬上



          大家好,我是Z哥。

          “這個 bug 的問題不是很明顯嗎?怎么這么久才搞定?”

          “就改一行代碼,你怎么弄了這么久?”

          我想上面的言語幾乎每個程序員都聽到過。特別是面對那些“稍懂技術(shù)”的同事的時候。


          我覺得這篇文章特別適合你收藏一下,為什么呢。首先,當(dāng)你再次遇到這種情況的時候,翻開這篇文章,可以幫助你降降火,讓你冷靜下來。其次,還能時不時地在朋友圈轉(zhuǎn)發(fā)給你的“稍懂技術(shù)”的同事看看,給他一些暗示,哈哈。

          很多人之所以會產(chǎn)生前面提到的這種誤區(qū),是因為他們潛意識里將工作量與代碼量掛鉤了。

          他們腦海里的程序員像電視電影的中的那些黑客那樣,palapala 地敲擊鍵盤,瘋狂地 coding,看上去都不帶思考的,然后軟件就寫成了。

          我們程序員當(dāng)然清楚,事情并不是這樣。不管是實現(xiàn)一個新功能還是修復(fù)一個線上 bug ,我們都不可能直接上手 coding,因為我們不知道代碼應(yīng)該寫在哪,怎么寫。


          /01  實際修 bug 的過程是怎樣的/

          就以修復(fù) bug 為例,常規(guī)的處理流程是這樣的。

          1. 確定 bug 相關(guān)的環(huán)境信息。

          2. 梳理 bug 所在的整條業(yè)務(wù)鏈路。

          3. 分析 bug 在鏈路中的哪個環(huán)節(jié)產(chǎn)生。

          4. 調(diào)整代碼,修復(fù)問題。


          其中的每一個環(huán)節(jié)都存在著增加時間的因素,我們來一個個展開。


          /02  每個環(huán)節(jié)影響時長的因素/

          01  確定 bug 相關(guān)的環(huán)境信息

          在這個環(huán)節(jié)最常見的情況是,反饋 bug 的人員無法清楚地描述 bug 所處的環(huán)境,甚至是描述出現(xiàn)錯誤(比如參雜了自己的主觀猜測,屏蔽了一些重要信息)。

          這會導(dǎo)致程序員排查 bug 的時候,方向就錯了,被誤導(dǎo)了。一旦方向錯了,不管花再多時間,都是白白浪費掉的。

          雖然說一線的業(yè)務(wù)人員,不懂技術(shù)是常態(tài),但是不可否認(rèn)的是,這的確會對修復(fù) bug 的時間產(chǎn)生很大影響。


          02  梳理 bug 所在的整條業(yè)務(wù)鏈路

          如果恰好這條業(yè)務(wù)鏈路我很熟悉,甚至是實現(xiàn)業(yè)務(wù)邏輯的代碼都是我寫的。那么這里花費的時間就少得多。但是如果不是的話,我還需要花時間去梳理業(yè)務(wù),然后找到業(yè)務(wù)對應(yīng)的代碼在哪些地方,它們之間是如何組成、協(xié)調(diào)的。

          這里可能存在的大坑是,這塊代碼不但我不熟悉,并且前人寫的代碼過于草率。此時,在幾百萬、上千萬行代碼的項目中,找到相關(guān)的幾千行代碼,并且捋清楚它們之間的關(guān)系,這可是個大工程,并不比把這個功能重新推翻重做容易。


          03  分析 bug 在鏈路中的哪個環(huán)節(jié)產(chǎn)生

          大多數(shù)人應(yīng)該都聽過斯坦門茨在福特生產(chǎn)線上畫一條線收了 1 萬美元的故事。他給福特開出的收據(jù)是:畫線 1 美元,知道畫在哪 9999 美元。

          解決 bug 也是這樣過,分析 bug 產(chǎn)生的根本原因才是最困難的過程。


          而且很多時候,一個 bug 所表現(xiàn)出來的現(xiàn)象與問題根源并沒有直接關(guān)系。

          比如,提交訂單提示庫存不足。其實并不是庫存不足,而是請求庫存 api 出現(xiàn)了異常,甚至是由于下游的庫存 api 內(nèi)部異常導(dǎo)致。這種層層依賴隨著業(yè)務(wù)鏈路的延伸會變得更加復(fù)雜,這自然需要大量的時間去抽絲剝繭。

          還有更夸張的情況是,完全沒有關(guān)系。比如,提示 XXX 失敗,實際卻是 YYY 的問題,因為這個提示語句是從其他代碼里 copy 過來的……(有遇到過這種情況的來評論區(qū)確認(rèn)過眼神一下)


          04  調(diào)整代碼,修復(fù)問題

          條條大路通羅馬,一個問題往往也有很多種解決方案。修復(fù)得快不代表修復(fù)得好,找到最簡單、最優(yōu)雅的解決方案是需要經(jīng)過思考的。

          哪怕是看似在確定的地方去修改代碼,如果你運氣不好,碰巧要修改的 function 對外有 100 多個引用,而且你還需要改動傳入的參數(shù)……

          此時,你得祈禱不會遇到那種牽一發(fā)而動全身情況,細(xì)品一下下面這張圖你就懂了。


          就算運氣不錯,修改的地方很容易搞定,但是如果在這個過程中發(fā)現(xiàn)了一些寫得有問題的代碼,比如容錯性差、性能差等情況。此時,作為有責(zé)任心的程序員,必須得出手去改掉啊。否則根據(jù)「墨菲定律」,后面還是得出問題,到時候如果自己還在負(fù)責(zé)這個項目的話,解決成本就更大了。

          而且,有更多責(zé)任心的程序員,還會舉一反三,去將自己知道存在同類問題隱患的代碼都去改掉。這也需要更多的時間。


          05  修復(fù)完后

          作為有責(zé)任心的程序員,并且出于對自己的口碑負(fù)責(zé),肯定不會將結(jié)果的驗證完全交由測試人員來做。

          所以,自己還得多花一些時間來驗證,自認(rèn)為容易出現(xiàn)問題的場景下是否還會出現(xiàn)問題。這,也需要時間。


          /03  提高修復(fù)bug效率的方法/

          當(dāng)然,上面這些理由也不是我們懶于提高修復(fù) bug 效率的借口,對于如何更高效地 Debug ,包括應(yīng)對生產(chǎn)環(huán)境的 bug ,可以看看我之前的老文。

          系統(tǒng)壞了,慌不慌
          如何提高Debug效率

          如果你想未雨綢繆,外加條件允許的話,建議把單元測試也做起來。

          聊聊單元測試


          好了,總結(jié)一下。

          這篇呢,Z哥和你聊了為什么很多時候修復(fù) bug 沒有想象中的那么快。

          因為在以下 4 個環(huán)節(jié)都存在著額外花費時間的事情。

          1. 確定 bug 相關(guān)的環(huán)境信息。

          2. 梳理 bug 所在的整條業(yè)務(wù)鏈路。

          3. 分析 bug 在鏈路中的哪個環(huán)節(jié)產(chǎn)生。

          4. 調(diào)整代碼,修復(fù)問題。


          所以,如果以后誰還說你為什么修 bug 那么慢,把這篇文章發(fā)給他。你說不出口的話,我替你說了。不過,后果自負(fù)哦~


          其實大家都不喜歡修 bug ,特別是在低質(zhì)量的代碼中反復(fù)修復(fù)同一類型的 bug 。但是現(xiàn)實中,好像也有不少的人嘴上說著這樣,但自己卻總是在寫這些低質(zhì)量的代碼?歡迎分享你與 bug 之間的精彩故事給我~



          推薦閱讀:


          原創(chuàng)不易,如果你覺得這篇文章還不錯,就「點贊」或者「在看」一下吧,鼓勵我的創(chuàng)作 :)


          也可以分享我的公眾號名片給有需要的朋友們。

          如果你有關(guān)于軟件架構(gòu)、分布式系統(tǒng)、產(chǎn)品、運營的困惑

          可以試試點擊「閱讀原文

          瀏覽 45
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          評論
          圖片
          表情
          推薦
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  欧美一级婬片免费视频黄 | 日韩欧美一级在线视频 | 黄片网在线观看 | 影音先锋男人资源av | 99热在线观看免费精品 |