有Bug不會解? 這篇文章很Nice ! 網友: 這套方法論太讚了 !

 

Bug是什麼?

來自百度百科的詞條定義

漏洞是在硬件、軟件、協議的具體實現或系統安全策略上存在的缺陷,從而可以使攻擊者能夠在未授權的情況下訪問或破壞系統。具體舉例來說,比如在Intel Pentium芯片中存在的邏輯錯誤,在Sendmail早期版本中的編程錯誤,在NFS協議中認證方式上的弱點,在Unix系統管理員設置匿名Ftp服務時配置不當的問題都可能被攻擊者使用,威脅到系統的安全。因而這些都可以認爲是系統中存在的安全漏洞。bug狹義的概念是指軟件程序漏洞或缺陷,廣義的概念還包括測試工程師或用戶所發現和提出的軟件可更改的細節、或與需求文檔存在差異的功能實現等。

綜上所述Bug 的定義有如下幾類

  • 軟件程序漏洞
  • 與原型不符的技術實踐
  • 業務場景中技術架構的缺陷(可靠性,可擴展性,可維護性)

如何發現Bug ?

第一種Bug的發現途徑, 主要靠滲透工程師的測試 或者來自黑客的管教. (比如 XSS, CSRF..) 第二種Bug的發現途徑, 主要靠項目交付後一行一行的執行測試用例與 有着火眼金睛的產品經理的把關. (比如 Ant Design 聖誕節日彩蛋) 而第三種Bug 則是最常見的. 對於業務認知與實踐上的欠缺, 有些Bug可能在上線前的自測種就能察覺到, 可有些Bug就隨着時間的流逝被雪藏了起來, 比如使用 JDK1.7的HashMap在多線程業務中導致的死鎖問題, 使用分詞器不建立單列模式加載語料包導致的OOM, 以及在金融場景使用 不安全的流式處理的漏算問題等等. 爆發之時, 宕機之日. 看完這麼多Bug發生方式, 有沒有一種 衆生皆苦 的感覺~

如何在Bug發生後Debug?

  1. 項目必須有日誌框架收集每天的日誌, 在計算密集型系統(單機)中需要捕獲Bug後將異常快照發往值班人員郵箱 , 而在數據密集型系統(分佈式)部署中需要引入 ElasticStack 分析日誌事件.

騰訊技術工程:騰訊技術課|基於Elastic Stack 搭建日誌分析平臺​zhuanlan.zhihu.com

2. 日誌框架可對易錯業務進行埋點, 而 ElasticStack 則可配置日誌分析事件. 方便Debug,

3. 上面的兩步操作是爲了獲取Bug發生後的第一現場. 有利於定位Bug.

4. 定位到了Bug ,就要沉住氣, 告訴自己告訴自己已經成功了一半, 什麼事情都可以解決, 要麼花錢要麼花時間, Bug一定會解決的.

5. 面對滿屏日誌, 不要慌. 日誌打印範圍從大到小分別爲 DEBUG , INFO , WARN , ERROR , 如果已經對易錯的業務埋點就使用 全局搜索 WARN , 大致看一眼下面有沒有錯誤的. 如果沒有則, 直接 搜索 ERROR , 從第一個 ERROR 開始看, 主要看 異常名和異常信息調用堆棧 然後根據 異常信息找到 發生 ERROR 的代碼行數, 接下來就是在自己的項目中找到異常的調用類, 打個斷點, 要想復現BUG需先將日誌級別調整爲 DEBUG, 這樣就可以輸出全部日誌, 然後去啓動當前項目. 一步一步Debug這個類直到異常再次復現.

6. 將當前項目中未提交代碼提交, 爲了避免解決Bug而引發的Bug, 根據自己對這個 Bug的理解去修復出現Bug的代碼, 然後在這個過程中去查資料, 去請教大佬,也是提升的一個過程 !

7. 對於初學者建議建立一個Bug手冊, 將自己知道的所有Bug 都記錄在上面, 以及相應的解決方案, 以便下次直接套用.

如何防止Bug發生?

首先研發團隊要有正視Bug的勇氣, Bug從有這個名字開始就一直存在到今天, 我相信 一百年以後仍然還有Bug存在, 只要代碼是人寫的, 人非聖賢熟能無過? 要有積極預防Bug的心態, 對於生產事故要理性對待, 從表面上看這是人的責任 但其本質其實是制度的問題, 比如以 蘋果公司的 iOS 和 OS X 系統的安全漏洞爲例

極客時間​time.geekbang.org

  • 第一道關:程序員(提高程序員的修養,是一個永不過時的課題。從別人的失敗和自己的失敗中學習、積累、提高,是一個程序員成長的必修課)
  • 第二道關:編譯器(編譯器在代碼質量方面,作爲機器,恪盡職守,它可以幫助我們清除很多錯誤)
  • 第三道關:迴歸測試 (一般地,軟件測試會儘可能地覆蓋關鍵邏輯和負面清單,以確保關鍵功能能夠正確執行,關鍵錯誤能夠有效處理)
  • 第四道關:代碼評審 (代碼評審是一個有效的在軟件研發過程中抵禦人類缺陷的制度)
  • 第五道關:代碼分析 (靜態代碼分析是通過對源代碼的檢查來發現潛在問題的一種軟件質量保障方式)

代碼製造的流水線我們分析了這重重關卡,我特別想傳遞的一個想法就是,編寫優秀的代碼,不能僅僅依靠一個人的戰鬥。代碼的優秀級別,依賴於每個關卡的優秀級別。高質量的代碼,依賴於高質量的流水線。每道關卡都應該給程序員提供積極的反饋。這些反饋,在保障代碼質量的同時,也能幫助程序員快速學習和成長。

 

公衆號名稱 20K+,  深入淺出分享 Java 乾貨 , 找回對代碼的 Passion , 助力月入 20K+ 

原文地址: https://mp.weixin.qq.com/s/e2arxLqnsbKZ_arFPTRwBw

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章