美團出現大面積系統崩潰，為了找BUG，JAVA培訓班的學員們吵翻了！

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

于是昨天中午靈機一動

準備點個外賣開心一下

打開美團選餐后

支付一次……失敗！

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

美團竟然扣了我兩次款！！！

這?是怎么肥事？

不行，我要給美團客服打電話投訴！

一撥過去！我的天！它竟然一直在占線！

實在忍受不了了

我要發個微博發泄一下并@它們官微

打開微博一看

原來美團出大事了！

美團微博已被千萬網友占領↓↓↓

原來美團服務器出現大面積崩潰，包括外賣、團購在內的業務均受到影響。外賣訂單付款出現延遲，部分用戶付款后系統仍提示尚未付款；團購頁面內容也無法正常顯示。

對于這個問題，美團外賣公開回應稱，非常抱歉給大家帶來了不便，因受系統網絡影響，導致部分用戶會出現重復支付情況，技術人員正在緊急處理，請大家先別著急，重復支付的款項會為大家原路退回，款項會在1-7個工作日內到賬。

影響了吃中午飯，這樣的回應顯然沒有平復廣大用戶的心情，有用戶爆料稱，從2014-2017年美團一直在崩潰，從未被完全修復，就拿最近來說，8月和10月都出現過一次。

對此，不少網友調侃：年終獎拿不到不說，這次美團的程序員可能要被炒魷魚了！

網友評論：

@lxl：美團的程序員這一年白干了

@MR無尾熊：用戶氣死了，餓了么笑死了，美團哭死了，程序員……沒了

@強行插入：程序員要被祭天了

@HEQQ：永遠不要小瞧一個飯點兒上餓暈網友的能量！

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

@風鳥一群：肯定不是小bug引起的，太瞧不起美團了。如果是網絡/服務架構問題，美團這次算是有了非常寶貴的經驗。

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

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

再說了，哪個程序員能保證，寫過的代碼里一個bug也沒有？其實，程序員工作的最大意義就是不停地尋找bug，戰勝bug啊，正所謂“程序不息，Bug不止”。

出現的bug都是程序員哪些錯誤造成的？

此次美團大面積崩潰事件，也在云和數據的JAVA班和PHP班引發了大討論，在云和數據JAVA班資深講師李老師看來，bug的出現一般是由程序員的代碼錯誤造成的。

那么，程序員在寫代碼時一般會犯哪些錯誤呢？李老師總結了以下幾點：

1　缺少必要的注釋

大段的if-else缺少注釋，讓維護者無法快速分辨分支邏輯。特定地方存在hack或復雜邏輯的代碼，缺少注釋會讓后來者不明所以。為了你好，也為了后來者好，請務必加上代碼。說不準以后還是由你來維護這段代碼。

2　不變和變化的部分拆分

程序員中流傳著一句話，此處不要寫死，將來必改。有經驗的程序員會將一些業務層的邏輯抽象出來，寫成配置文件，好處就是若后續需求有改變，只需改配置文件即可，肯定不會引入bug。

3　忽視測試部分

程序員中又流傳著一句話，沒有測試的代碼等于沒寫。雖不敢全部贊同，卻也有幾分道理。從測試用例驅動開發，持續集成，每次編譯自動跑測試用例，能夠保證系統的穩定同時也減輕測試成本。自己改的的部分做好自測，理解需求，做一個有責任心的工程師。

4　直接操作數據

你應該通過方法去操作數據，而不是直接操作數據,這樣能夠保證你總能操作數據正確。例如一個類中定義的屬性發生變化了，代碼中所有涉及到直接操作該屬性的代碼都需要修改。如果通過方法操作該屬性，則僅需修改操作方法，對于外部調用者，類屬性變化被屏蔽了，遵循了解耦的原則，代碼穩定性大大提高。

5　缺乏文檔或文檔質量低下

前期文檔很重要，不論是框架的API使用手冊，還是需求或設計文檔，以及各種既定流程的規范，不同種類的模板及核對表，等等這些文檔，對于項目來說都是非常重要的資源。而往往有些項目，這類文檔就是交由非軟件行業的人員來編寫，或者前期根本不打算在文檔上浪費時間。

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

對于一名程序員來說，尤其是編程初學者，如何在復雜代碼中找到bug，是一種能力的考驗。

關于如何找bug，云和數據JAVA班的學員們引發了一場大討論，看看他們有哪些自己獨到的方法：