在最近的一週,我維護的業務系統出現了不少壞毛病,一週七天crash掉了4次,每次都須要都是由於一點很小的問題,觸發了蝴蝶效應,致使整個系統全盤崩潰,因而產生除了敘述本篇的想法,固然這並非爲了掩蓋我在Coding上的一些細節處理和職責疏忽,只是爲了從根本的細節上去分析這些問題。程序員
首先咱們須要嘗試理解一下什麼Bug?數據庫
關於bug的解釋ide
bug 是指任何計算機程序或硬件系統中的錯誤,故障或缺陷。錯誤會產生意外結果或致使系統意外運行
簡單來講:bug就是程序出了問題,產生了意外的結果,沒有按照預期的結果去運行。函數
產生Bug的緣由有不少種:工具
以上緣由總結,主觀和客觀因素都會影響到Bug的產生,正如偏差不可避免通常,咱們應該對本身寫出的代碼進行測試、分析、"溝通".學習
鑑於以上bug產出的緣由,咱們能夠經過這些一些對策來避免Bug的產生,下面是一些常見緣由分析和處理對策。測試
1.開發者水平過低this
在進行系統的構建中,部分開發者可能一般由於開發經驗過少,或者語言不熟悉,會編寫錯誤的代碼,而後未通過代碼測試和審計,便進行提交和上線操做,致使了異常的引起編碼
解決方案:spa
2.不一樣的編譯及運行環境
由於業務的拓展和服務支持,須要部署多個不一樣的運行環境中,如:轉帳系統,你在測試環境中轉帳了1000元給用戶小明,小明卻在生產環境中收到了這1000元,併成功進行提現,每每由於沒有環境判斷,致使了失誤的操做!
解決方案:
1.在代碼中多進行註釋說明,標明哪些函數會在其餘環境中操做和運行
2.增強環境邏輯判斷
如下是我在使用的一些標註和說明,其餘開發者或我本人再次閱覽該代碼時,就會獲得一個清晰的運行結果.
/** * 執行該函數時,會根據env環境進行處理,詳細以下 * prod(生產環境):會啓動隊列對視頻進行轉碼、截圖、寫入到生產數據庫中操做. * staging(預演環境):不會啓動隊列,但會寫入staging數據庫中 * test(測試環境):會啓動隊列對視頻進行轉碼、截圖、寫入到測試數據庫中操做. */ $video = $this->uploadVideo($file); $queue = $this->videoQueue($video);
3.與需求方溝通不到位
這是常常程序員與產品對撕的一個很重要緣由,TA想要A,而你卻作出了B,因而大家產生了很大的爭論
解決方案:
4.馬虎大意、考慮不周
編碼時覺得問題很小,修改代碼,不走調試與測試流程,直接上線.
解決方案:
5.放飛自我,Coding全靠自嗨
解決方案:
無
這類朋友不適合作開發者,適合去作創造者!
6.選擇了錯誤的或者運行不穩定的第三方庫
有時候爲了省略接入時間,每每會忽略掉一些大型庫,由於業務的支持只用到了一小部分,因此咱們有時候會去選擇一些mini庫,最後因爲不穩定或方案不成熟,出現錯誤的運行結果
解決方案:
「橡皮鴨調試法」是我在閱讀《編寫可讀代碼》一書中看到的一個技巧,我在一我的開發的時候會使用這個技巧,我認爲是一個不錯的選擇.
咱們爲何會編寫BUG,若是沒有BUG?開發和測試不就失業了嗎?固然這只是一句玩笑話。
在此引用知乎上一句頗有意思的話.
編碼也亦如此,由於不少主觀和客觀的因素,致使程序執行了錯誤的邏輯,產生了不如預期的結果,做爲一個合格的開發人員,咱們應該盡力確保程序穩妥運行,減小失誤和異常。
正如CZG提到的"你寫的每一行代碼,都是你的名片",咱們每一個人都義務去維護好這張名片,讓其餘人對這張名片充滿敬畏之心,而不是"what shit code",諸君共勉!