最近公司食堂的飯菜真是吃夠了

于是昨天中午靈機(jī)一動(dòng)

準(zhǔn)備點(diǎn)個(gè)外賣開心一下

打開美團(tuán)選餐后

支付一次……失??！

于是我再支付一次，然后……

美團(tuán)竟然扣了我兩次款?。?！

這?是怎么肥事？

不行，我要給美團(tuán)客服打電話投訴！

一撥過(guò)去！我的天！它竟然一直在占線！

實(shí)在忍受不了了

我要發(fā)個(gè)微博發(fā)泄一下并@它們官微

打開微博一看

原來(lái)美團(tuán)出大事了！

美團(tuán)微博已被千萬(wàn)網(wǎng)友占領(lǐng)↓↓↓

原來(lái)美團(tuán)服務(wù)器出現(xiàn)大面積崩潰，包括外賣、團(tuán)購(gòu)在內(nèi)的業(yè)務(wù)均受到影響。外賣訂單付款出現(xiàn)延遲，部分用戶付款后系統(tǒng)仍提示尚未付款；團(tuán)購(gòu)頁(yè)面內(nèi)容也無(wú)法正常顯示。

對(duì)于這個(gè)問題，美團(tuán)外賣公開回應(yīng)稱，非常抱歉給大家?guī)?lái)了不便，因受系統(tǒng)網(wǎng)絡(luò)影響，導(dǎo)致部分用戶會(huì)出現(xiàn)重復(fù)支付情況，技術(shù)人員正在緊急處理，請(qǐng)大家先別著急，重復(fù)支付的款項(xiàng)會(huì)為大家原路退回，款項(xiàng)會(huì)在1-7個(gè)工作日內(nèi)到賬。

影響了吃中午飯，這樣的回應(yīng)顯然沒有平復(fù)廣大用戶的心情，有用戶爆料稱，從2014-2017年美團(tuán)一直在崩潰，從未被完全修復(fù)，就拿最近來(lái)說(shuō)，8月和10月都出現(xiàn)過(guò)一次。

對(duì)此，不少網(wǎng)友調(diào)侃：年終獎(jiǎng)拿不到不說(shuō)，這次美團(tuán)的程序員可能要被炒魷魚了！

網(wǎng)友評(píng)論：

@lxl：美團(tuán)的程序員這一年白干了

@MR無(wú)尾熊：用戶氣死了，餓了么笑死了，美團(tuán)哭死了，程序員……沒了

@強(qiáng)行插入：程序員要被祭天了

@HEQQ：永遠(yuǎn)不要小瞧一個(gè)飯點(diǎn)兒上餓暈網(wǎng)友的能量！

@諸葛亮：我就知道我的午餐沒了，是美團(tuán)程序員背鍋，作為程序猿，我很理解

@風(fēng)鳥一群：肯定不是小bug引起的，太瞧不起美團(tuán)了。如果是網(wǎng)絡(luò)/服務(wù)架構(gòu)問題，美團(tuán)這次算是有了非常寶貴的經(jīng)驗(yàn)。

@差不多KK：嚇的我趕緊藏好寫好的bug

其實(shí)，從每天給程序員打交道的小編的角度看，把全部責(zé)任歸咎到美團(tuán)程序員的身上并不公平，要知道程序員身上承受的壓力該有多大呀！

再說(shuō)了，哪個(gè)程序員能保證，寫過(guò)的代碼里一個(gè)bug也沒有？其實(shí)，程序員工作的最大意義就是不停地尋找bug，戰(zhàn)勝bug啊，正所謂“程序不息，Bug不止”。

出現(xiàn)的bug都是程序員哪些錯(cuò)誤造成的？

此次美團(tuán)大面積崩潰事件，也在云和數(shù)據(jù)的JAVA班和PHP班引發(fā)了大討論，在云和數(shù)據(jù)JAVA班資深講師李老師看來(lái)，bug的出現(xiàn)一般是由程序員的代碼錯(cuò)誤造成的。

那么，程序員在寫代碼時(shí)一般會(huì)犯哪些錯(cuò)誤呢？李老師總結(jié)了以下幾點(diǎn)：

1　缺少必要的注釋

大段的if-else缺少注釋，讓維護(hù)者無(wú)法快速分辨分支邏輯。特定地方存在hack或復(fù)雜邏輯的代碼，缺少注釋會(huì)讓后來(lái)者不明所以。為了你好，也為了后來(lái)者好，請(qǐng)務(wù)必加上代碼。說(shuō)不準(zhǔn)以后還是由你來(lái)維護(hù)這段代碼。

2　不變和變化的部分拆分

程序員中流傳著一句話，此處不要寫死，將來(lái)必改。有經(jīng)驗(yàn)的程序員會(huì)將一些業(yè)務(wù)層的邏輯抽象出來(lái)，寫成配置文件，好處就是若后續(xù)需求有改變，只需改配置文件即可，肯定不會(huì)引入bug。

3　忽視測(cè)試部分

程序員中又流傳著一句話，沒有測(cè)試的代碼等于沒寫。雖不敢全部贊同，卻也有幾分道理。從測(cè)試用例驅(qū)動(dòng)開發(fā)，持續(xù)集成，每次編譯自動(dòng)跑測(cè)試用例，能夠保證系統(tǒng)的穩(wěn)定同時(shí)也減輕測(cè)試成本。自己改的的部分做好自測(cè)，理解需求，做一個(gè)有責(zé)任心的工程師。

4　直接操作數(shù)據(jù)

你應(yīng)該通過(guò)方法去操作數(shù)據(jù)，而不是直接操作數(shù)據(jù),這樣能夠保證你總能操作數(shù)據(jù)正確。例如一個(gè)類中定義的屬性發(fā)生變化了，代碼中所有涉及到直接操作該屬性的代碼都需要修改。如果通過(guò)方法操作該屬性，則僅需修改操作方法，對(duì)于外部調(diào)用者，類屬性變化被屏蔽了，遵循了解耦的原則，代碼穩(wěn)定性大大提高。

5　缺乏文檔或文檔質(zhì)量低下

前期文檔很重要，不論是框架的API使用手冊(cè)，還是需求或設(shè)計(jì)文檔，以及各種既定流程的規(guī)范，不同種類的模板及核對(duì)表，等等這些文檔，對(duì)于項(xiàng)目來(lái)說(shuō)都是非常重要的資源。而往往有些項(xiàng)目，這類文檔就是交由非軟件行業(yè)的人員來(lái)編寫，或者前期根本不打算在文檔上浪費(fèi)時(shí)間。

程序員都是怎樣找到bug的？

對(duì)于一名程序員來(lái)說(shuō)，尤其是編程初學(xué)者，如何在復(fù)雜代碼中找到bug，是一種能力的考驗(yàn)。

關(guān)于如何找bug，云和數(shù)據(jù)JAVA班的學(xué)員們引發(fā)了一場(chǎng)大討論，看看他們有哪些自己獨(dú)到的方法：