這里的粉絲大多數(shù)可能還是做技術(shù)的蓝纲，哪怕不是做技術(shù)的阴孟，只要在互聯(lián)網(wǎng)行業(yè)的話可能平時(shí)也會(huì)或多或少和技術(shù)人員打交道。

這是一篇半娛樂性的吐槽文章税迷，權(quán)當(dāng)給廣大技術(shù)人員解解悶：）永丝。

哈哈哈，然后我要開始講一個(gè)經(jīng)常在發(fā)生的事實(shí)了箭养。（程序員們可能會(huì)感到一些不適）

99.999999999%做技術(shù)的都會(huì)被問到或者被吐槽到：“你的程序怎么又出bug了慕嚷！”

這個(gè)問題讓程序員頭疼。。

反正喝检，我作為程序員的內(nèi)心世界是：如同一萬只草泥馬飛奔而過嗅辣，難以壓抑內(nèi)心的激動(dòng)，每次都差點(diǎn)忍不住想說“你寫篇幾百字的作文還有錯(cuò)別字呢挠说，我碼個(gè)幾萬行的代碼還不允許出錯(cuò)了澡谭？“

可能同樣是做技術(shù)的你此時(shí)在不斷點(diǎn)頭，哈哈损俭。

但是這么講畢竟也緩解不了矛盾蛙奖，我們還是得擺事實(shí)講道理不是？

啥都不怕杆兵，就怕程序員有文化雁仲！

所以，小編想來帶你好好分析一下這個(gè)事情拧咳，當(dāng)你再遇到這個(gè)情況的時(shí)候伯顶，可以拿這些觀點(diǎn)來反駁（不是做技術(shù)的也可以了解下程序員的難處，誰沒個(gè)難處呢骆膝，多多包容）

什么是Bug

任何一個(gè)「問題」的產(chǎn)生祭衩，本身是沒有好壞之分的，但是為什么會(huì)有的就不被care阅签，甚至還會(huì)很喜歡掐暮，而有的會(huì)被吐槽呢？根本原因是因?yàn)楫a(chǎn)生了利益損失政钟。

比如年前拼多多出問題送了很多無門檻券路克。

作為一個(gè)用戶，自然很喜歡养交，夸你夸到飛起精算，怎么會(huì)吐槽你呢。但是作為利益損失方碎连，必然破口大罵灰羽，害我傾家蕩產(chǎn)！

所以鱼辙，如果沒有產(chǎn)生利益損失廉嚼，我想其他人也不會(huì)來找你吐槽。

但是「問題」就等于「bug」嗎倒戏？我認(rèn)為并不是怠噪，「問題」不等于「 bug」。

因?yàn)槌绦騿T的職責(zé)是什么杜跷？拿造房子來比喻的話傍念，我認(rèn)為最核心的工作真的和“搬磚”（非貶義詞）無異矫夷，就是根據(jù)設(shè)計(jì)師（產(chǎn)品經(jīng)理）設(shè)計(jì)好的設(shè)計(jì)圖砌磚（編碼），建成和設(shè)計(jì)圖紙上一模一樣的建筑捂寿。

所以口四，如果一個(gè)東西造出來與設(shè)計(jì)不符，那么它可以說是bug或者缺陷（缺斤少兩不完整）秦陋。否則蔓彩，并不是bug，但可以被稱之為「漏洞」（完全沒考慮到的）驳概，表示不在預(yù)料之內(nèi)的情況赤嚼。

之前看到過一個(gè)形象的比喻：你家里的窗可以從外面打開，那叫漏洞顺又。你家里的窗打不開更卒，那叫bug。

但是要承認(rèn)稚照，bug是必然存在的蹂空。為什么？它是如何出現(xiàn)的呢果录？

Bug是如何出現(xiàn)的

正如前面所說上枕，程序員做的是“造房子”的事情。這件事完整的步驟分為3步弱恒。

1. 與產(chǎn)品經(jīng)理討論并確定功能（確定一個(gè)可以實(shí)現(xiàn)的設(shè)計(jì)圖紙）
2. 將每個(gè)單獨(dú)的元件抽象出來（確定施工方案）
3. 將相關(guān)的元件實(shí)現(xiàn)并進(jìn)行組合辨萍，完成建設(shè)（帶上材料開始施工）

第一步，“與產(chǎn)品經(jīng)理討論并確定功能”主要是溝通返弹，靠“看”和“理解”锈玉。

但是溝通本身是一個(gè)有損耗的過程，特別是在職責(zé)非常明確的組織中义起，產(chǎn)品經(jīng)理啪啦啪啦講了很多拉背，到實(shí)際做的時(shí)候你必然還是會(huì)去翻閱需求原型、需求文檔之類的重新理解一下默终。這個(gè)時(shí)候就是一個(gè)非常危險(xiǎn)的時(shí)期去团。

比如像下面這個(gè)的答案是什么？

這個(gè)問題讓程序員頭疼穷蛹。。

答案是17昼汗？不對(duì)肴熏。

我猜你可能沒注意到這些地方。

這個(gè)問題讓程序員頭疼顷窒。蛙吏。

為了讓你有深刻的印象源哩，這個(gè)舉例可能比較刻意和夸張一些，但是我想在你的身邊鸦做，由于沒注意到或者理解有誤的現(xiàn)象肯定很常見励烦。

溝通是相互的，這鍋只讓程序員背的話的確太委屈了點(diǎn)泼诱。

第二步坛掠，“將每個(gè)單獨(dú)的元件抽象出來”這主要是一個(gè)人抽象能力的體現(xiàn)。

但是抽象是啥治筒？抽象是“透過現(xiàn)象看到本質(zhì)”的能力屉栓，這個(gè)能力理論上是可以無限增長(zhǎng)的。隨著你對(duì)相關(guān)信息的掌握越多耸袜，這個(gè)能力會(huì)越強(qiáng)友多，會(huì)無限趨近于100%，但永遠(yuǎn)不會(huì)真正達(dá)到100%堤框，因?yàn)闆]人知道怎么才算100%域滥。

所以，當(dāng)你具備的信息沒那么多的時(shí)候蜈抓，是不是就抽象的不是那么合理启绰？不合理會(huì)導(dǎo)致什么？雖然不會(huì)直接產(chǎn)生bug资昧，但是會(huì)更容易產(chǎn)生bug酬土。但是人不都是需要經(jīng)歷這么一個(gè)成長(zhǎng)的過程么？

可以說格带，精通一項(xiàng)能力的背后都是踩著無數(shù)的bug過來的撤缴。要么在來這個(gè)組織之前已經(jīng)踩過了，要么在這個(gè)組織里踩叽唱。因此屈呕，前者的薪資也比后者高。

所以棺亭，如果過分苛求沒有bug虎眨，等于是在扼殺每個(gè)人成長(zhǎng)的機(jī)會(huì)，并且在透支未來的可能性镶摘。人會(huì)變得非常保守嗽桩、不敢嘗試新事物。

但是外部環(huán)境在不斷變化凄敢，新事物總會(huì)被動(dòng)的需要去接納（技術(shù)的更新越來越快碌冶，趨勢(shì)不可逆），然而對(duì)新事物的接受能力又得不到鍛煉涝缝，一旦遇到這種情況扑庞，在接觸新事物的時(shí)候會(huì)產(chǎn)生更多的問題（欠下的債總要還的）譬重。

第三步，“將相關(guān)的元件實(shí)現(xiàn)并進(jìn)行組合罐氨，完成建設(shè)”這就是實(shí)際的coding過程臀规，而coding是一個(gè)主觀的，完全由人主觀掌控的事情栅隐。

人畢竟不是機(jī)器塔嬉，不可能不犯錯(cuò)，就如前面提到的寫文章的時(shí)候出現(xiàn)錯(cuò)別字一樣约啊。

可能你會(huì)說邑遏，有測(cè)試人員啊，測(cè)試的工作不就是通過逆向思維來給程序員查缺補(bǔ)漏嗎恰矩？

的確是的记盒，但測(cè)試的介入只是降低錯(cuò)誤率，只是讓不出現(xiàn)bug的概率小數(shù)點(diǎn)后多幾位

外傅，指望發(fā)現(xiàn)100%的問題還是不太現(xiàn)實(shí)的纪吮。至少在當(dāng)下的條件下是這樣，為什么呢萎胰？因?yàn)榇a的本質(zhì)是各種邏輯的組合碾盟。

比如，一個(gè)完整的業(yè)務(wù)流程有10個(gè)環(huán)節(jié)技竟，每個(gè)環(huán)節(jié)有3種可能性冰肴，這是一個(gè)什么復(fù)雜度的系統(tǒng)？3 ^ 10 = 59049個(gè)分支（理論上存在的可能性數(shù)量）榔组，想要100%覆蓋這些場(chǎng)景熙尉，付出的成本幾乎是不可接受的。

然而我們實(shí)際的系統(tǒng)中遇到的個(gè)別場(chǎng)景甚至還要復(fù)雜的多搓扯。

其實(shí)每個(gè)正在運(yùn)行的系統(tǒng)都有bug检痰，包括我們每天在使用一些熱門系統(tǒng)（玩游戲的小伙伴們肯定熟悉“卡bug”這個(gè)詞）。只是這些bug有沒有被執(zhí)行到锨推，有沒有被發(fā)現(xiàn)铅歼，被多少人發(fā)現(xiàn)而已。

那么换可，我們只能舉手投降嗎椎椰？那倒不至于，辦法還是有的沾鳄。

減少bug的慣性想法

首先最容易想到的一點(diǎn)是俭识，增加測(cè)試人員。

這也是最容易看得到的“成本”一種方式洞渔，畢竟招一個(gè)人就得支出一份工資啊套媚。所以，增加測(cè)試人員這個(gè)方案是最不容易被老板們采納的方案磁椒。除非你可以說服這個(gè)人力成本的投入小于獲得的價(jià)值堤瘤。

另外，這個(gè)方案其實(shí)還增加了溝通成本浆熔，溝通的「隱性成本」其實(shí)非常大本辐，但是往往容易被忽略。（關(guān)于溝通成本医增，感興趣的可以看我之前寫的《就簡(jiǎn)單聊聊溝通效率問題》）

其次會(huì)想到的就是程序員代碼寫的嚴(yán)謹(jǐn)一點(diǎn)慎皱，仔細(xì)一點(diǎn)啊。這也是一種缺啥補(bǔ)啥的慣性思維叶骨。

先撇開到底能不能達(dá)到嚴(yán)謹(jǐn)一點(diǎn)茫多，仔細(xì)一點(diǎn)的目的。那怕達(dá)到了忽刽，他會(huì)產(chǎn)生什么結(jié)果呢天揖？可能是下面3種。

1. 更多的條件驗(yàn)證
2. 更多的單元測(cè)試
3. 更多的抽象提煉

可以確定的是跪帝，這些工作會(huì)增加2樣硬性的東西今膊，投入的時(shí)間和整體的復(fù)雜度。時(shí)間很好理解伞剑，我們就來聊聊復(fù)雜度斑唬。

一個(gè)常識(shí)是，越簡(jiǎn)單的東西越不容易產(chǎn)生bug黎泣。比如1+1=2恕刘，出現(xiàn)bug的可能性無非就是加號(hào)寫成來減號(hào)，1寫成了4之類聘裁。但是雪营，1+1=2，并且1*1=1衡便，并且1/1=1献起，。镣陕。谴餐。等等這些驗(yàn)證條件越多，那么由于驗(yàn)證條件自身的錯(cuò)誤而產(chǎn)生問題的可能性反而更多呆抑。

所以岂嗓，代碼的復(fù)雜度和產(chǎn)生bug的概率是成正比的，并且具有「邊際效用遞減」的效果鹊碍。這就意味著厌殉，做更多的驗(yàn)證帶來的收益會(huì)越來越小食绿。

這個(gè)問題讓程序員頭疼。公罕。

因此器紧，這個(gè)方案哪怕真能執(zhí)行到位，也不是一個(gè)特別好的方案楼眷。

那有沒有相對(duì)靠譜一些的辦法呢铲汪？有，但需要我們換一個(gè)角度來看待這個(gè)問題罐柳。

換一個(gè)角度看待bug

既然無法100%避免bug掌腰，那我們可以換個(gè)角度考慮一下，如何讓解決bug的過程更快张吉，甚至快到你都沒有察覺齿梁。

解決bug主要就是做2件事，找到bug的產(chǎn)生點(diǎn)芦拿，然后修復(fù)它士飒。

每天都在解決bug的程序員們應(yīng)該知道，這事最費(fèi)時(shí)間的是“找bug”的過程蔗崎。

因?yàn)椤靶迯?fù)bug”是一個(gè)技術(shù)性問題酵幕，這個(gè)對(duì)不同人的差異其實(shí)是很小的，因?yàn)槌绦騿T們每天在寫的代碼都是差不多的缓苛，非常同質(zhì)化的芳撒，況且還有標(biāo)準(zhǔn)答案“文檔”可以參考。比如未桥，都知道string.concat()是拼接笔刹，string.split()是分割。該用分割的地方不小心用了拼接冬耿，那改掉就好舌菜。

但是“找bug”就不是這樣了。比如亦镶，你剛剛改完一行代碼后發(fā)布出現(xiàn)的問題日月，你不用找就知道問題出現(xiàn)在哪。但是讓你排查一個(gè)剛接手沒多久的系統(tǒng)肯定是一臉懵逼缤骨。

根本原因在于爱咬，這個(gè)過程不像技術(shù)性問題具有確定性，它是充滿不確定性的绊起，處在一個(gè)“混沌”的環(huán)境中精拟。

所以，對(duì)待bug的重點(diǎn)就變成了：如何更快的發(fā)現(xiàn)和找到bug。

關(guān)于這點(diǎn)Z哥的建議是：

1. 打好日志
2. 學(xué)會(huì)利用工具
3. 每次的迭代規(guī)模盡可能的小

首先蜂绎，打好日志栅表。日志其實(shí)就是我們?cè)诰幋a的時(shí)候安插在程序中“記錄員”，它替我們記錄著我們認(rèn)為容易出現(xiàn)問題的地方所產(chǎn)生的信息荡碾。

但是系統(tǒng)無時(shí)無刻都在運(yùn)行著谨读，必然會(huì)產(chǎn)生大量的日志信息，如何從這些信息中快速的找到關(guān)鍵信息坛吁，就是需要考慮的問題。

另外铐尚，如果每個(gè)人都隨意的用自己喜歡的記錄日志的方式拨脉，那么從風(fēng)格迥異的日志中找你需要的信息就變得很頭疼，時(shí)間不一致宣增，格式不一致等等玫膀。

所以，要做好打日志這個(gè)事情爹脾，就需要定義一個(gè)標(biāo)準(zhǔn)帖旨，比如必須要有時(shí)間，包含當(dāng)前上下文的參數(shù)等等灵妨。

我們還可以給日志做一下歸類解阅，定義不同的日志級(jí)別，在記錄的時(shí)候帶上前綴泌霍。比如【info】货抄、【warning】、【error】之類朱转。如此一來蟹地，平時(shí)更著重關(guān)注的就是error級(jí)別的信息，而且由于將其他級(jí)別的信息剝離了出去藤为，使得這里的數(shù)據(jù)量大大減少怪与，更便于查看。

不過缅疟，日志記錄畢竟是一個(gè)在做“預(yù)判”分别，如果日志中沒有記錄到怎么辦呢？這里提醒大家不要先想著怎么調(diào)試窿吩。

如果你面對(duì)的系統(tǒng)是一個(gè)單體應(yīng)用倒還好茎杂。如果你面對(duì)的是一個(gè)大型的分布式系統(tǒng)，調(diào)試的效率低不說纫雁，這事你一個(gè)人可能還完不成煌往。而且，如果你直接調(diào)試生產(chǎn)環(huán)境的話，說不準(zhǔn)還會(huì)產(chǎn)生什么副作用刽脖，攤上新的問題羞海。

找bug本質(zhì)上是一個(gè)排除法的過程，設(shè)斷點(diǎn)調(diào)試也是如此曲管。但是從起點(diǎn)開始一步一步的做排除法效率太低了却邓。應(yīng)該先通過自己的經(jīng)驗(yàn)、擁有的部分信息先邏輯推理一下院水，縮小排查的范圍腊徙。哪怕你最終還是需要調(diào)試的話，先做這個(gè)事情也會(huì)讓后續(xù)的工作更高效一些檬某。

第二點(diǎn)撬腾，利用工具。這里的“工具”不要簡(jiǎn)單的理解成利用“調(diào)試工具”恢恼。正如上面提到的民傻，找bug的本質(zhì)是一個(gè)排除法的過程，那么任何能夠幫你更高效的做排除法的工具都是可以利用的场斑。比如漓踢，

• 從系統(tǒng)的「事件查看器」中獲取更多的環(huán)境信息。
• 利用windows平臺(tái)的windbg漏隐、lunix平臺(tái)的MAT之類的工具直接分析抓到的dump文件喧半。
• 借助可視化工具更高效的發(fā)現(xiàn)問題，如FlameGraph等锁保。

另外薯酝，如果能主動(dòng)的告訴你哪里出現(xiàn)bug了，就更棒了爽柒。所以吴菠，我們可以搭建一套查看方便，信息同步及時(shí)的日志框架浩村，以便讓有價(jià)值的信息第一時(shí)間呈現(xiàn)在你的面前做葵。如果有高效的篩選功能就更好了。

很多日志框架小編沒用過心墅，就不發(fā)表什么言論了酿矢，但是elasticsearch + logstash + kibana這套用起來還是很爽的，體系也比較成熟怎燥，部署起來也很簡(jiǎn)單瘫筐，大家可以嘗試一下。再配上ElastAlert或者Sentinl铐姚，可以把實(shí)時(shí)預(yù)警機(jī)制也包含了策肝。

最后肛捍，每次的迭代規(guī)模盡可能的小。這個(gè)說起來容易之众，做起來難拙毫，因?yàn)檫@是由整個(gè)團(tuán)隊(duì)的文化來決定的。這個(gè)點(diǎn)的內(nèi)容完全可以單獨(dú)開一篇講棺禾，這里就簡(jiǎn)要闡述下缀蹄。

MVP（Minimum Viable Product）式的小步快跑，其實(shí)除了讓系統(tǒng)或者產(chǎn)品的功能演進(jìn)更科學(xué)之外膘婶，還可以讓每次迭代所面臨的風(fēng)險(xiǎn)更小缺前。正如前面提到的，你改一行代碼發(fā)布上去悬襟，如果出問題诡延，你說問題在哪？

相對(duì)的古胆，再想象一下，一次性發(fā)布一個(gè)開發(fā)了半年的版本筛璧，前一晚能睡的安穩(wěn)不逸绎？

總結(jié)

好了，我們總結(jié)一下夭谤。

這篇呢先闡述了我對(duì)“什么是bug”的理解棺牧，然后分析了bug是如何產(chǎn)生的，以及我們可能會(huì)做的一些慣性選擇朗儒。

最后給你的建議是颊乘，以如何更快的找到bug為出發(fā)點(diǎn)來考慮。通過「打好日志」醉锄、「學(xué)會(huì)利用工具」乏悄、「每次的迭代規(guī)模盡可能的小」這3種方式來進(jìn)行。

不過話說回來恳不，雖然我們無法避免出bug（一個(gè)項(xiàng)目開發(fā)完后沒測(cè)出bug檩小？你問任何一個(gè)技術(shù)人員都說“做夢(mèng)呢”），但是爭(zhēng)取讓bug更少是我們的本職工作烟勋。

因?yàn)閷?duì)bug容忍度低的另一層含義是规求，大家對(duì)系統(tǒng)的依賴越來越重，越來越多的事情在通過程序完成卵惦，而不是人力阻肿。

資料獲取方式

歡迎工作一到五年的Java程序員朋友們加入Java架構(gòu)交流：810589193
本群提供免費(fèi)的學(xué)習(xí)指導(dǎo) 架構(gòu)資料 以及免費(fèi)的解答
不懂得問題都可以在本群提出來 之后還會(huì)有職業(yè)生涯規(guī)劃以及面試指導(dǎo)

還有Java工程化、高性能及分布式沮尿、高性能丛塌、高架構(gòu)。性能調(diào)優(yōu)、Spring姨伤，MyBatis哨坪，Netty源碼分析和大數(shù)據(jù)等多個(gè)知識(shí)點(diǎn)高級(jí)進(jìn)階干貨