不怕一萬，只怕萬一呀，朋友。
從前，有個程式設計師叫小明，他在開發一**票的投資組合功能。這個功能簡單的來說，就是乙個投資組合裡有現金、**等資產，我們根據組合裡**漲跌等情況，給出乙個整體組合的指數，以評判組合的水平。
聰明的小明在開發的時候就發現了，如果存在現金為0，並且所持有的**都退市了的話，這**票指數的計算就會存在問題。小明想：「現金為0的情況很少，退市的情況就更不多，這個情況很極端，肯定不會遇到，實現異常情況處理的邏輯也很複雜，測試肯定也發現不了，不管了」，於是**就歡快地跑到了線上。
隨著業務的發展，投資組合越來越多了，也隨著政策的轉向，退市的**也陸陸續續地變多了。某一天，夜裡跑批報錯了！告警簡訊在夜裡發到了小明的手機了，小明只好半夜跑來公司排查問題，原來之前考慮的情況真的出現了，小明心裡暗罵了一句，還tm真的出現這情況了！罵歸罵，小明運用他聰明的大腦，重新看了一遍邏輯，分析了各種情況，然後給出了在這種情況下指數的跑批值應該是多少，經過一次又一次戰戰兢兢的複核計算，最後戰戰兢兢地把資料一條一條地更新到了資料庫。經過一番折騰後，已經快早上5點了...第二天跟領導解釋了情況，說這種情況很少見，我們後續抽時間把這塊的邏輯補上！
然而在這次事故的不久之後，小明還在想啥時候開始補這塊邏輯時，小明夜裡又收到了投資組合模組的告警簡訊.....
從前，有另外乙個程式設計師叫小王，他在做乙個完成交易時給使用者的積分賬號加積分的功能，訂單與積分在不同的資料庫，這涉及到乙個分布式事務的問題。
聰明的小王早就知道了有很多形態可以解決這個問題，最合適的當然是mq，但是目前系統沒有mq要額外加入維護，很麻煩；tcc也可以，但要寫額外的**，也好煩；2pc嘛，好像沒有合適的，效能也據說不高，不選；best efforts 1pc,這個不錯！效能比2pc高，無需額外編碼，大多數情況下能有強一致性保證，唯一可能出現異常的情況就是在commit階段，若乙個資料庫事務提交了，另外乙個資料庫事務由於宕機提交失敗的話，才會出現不一致，這情況多少見呀！就best effors 1pc啦！出問題我手工給他補上就好啦。
於是**就輕鬆愉快地上線了。
隨著業務的發展，業務範圍和交易量也在逐步地變大，小王寫了乙個新功能準備更新到交易服務裡，公司裡有超強的滾動發布，上線過程很愉快的就完成了。完成驗證後，小王心滿意足地跑回家睡覺了。
這個小王比較幸運，睡到了第二天上班。然後客服部傳來訊息，說客戶投訴，其交易沒有產生積分！小王一下子就猜測到可能是昨晚滾動公升級服務下線的時候，沒有做優雅停機相關**設計，導致best effors 1pc失敗了，於是小王翻了下日誌和資料，排查出果然是這個問題導致的，實際還有額外幾條資料也有這問題，小王一併修復了這些資料問題，雖然小王很聰明，但這個修復過程也占用小王一上午的時間。同時，小王也決定，給加上優雅停機的相關邏輯。後來再也沒有出現過由於更新導致的不一致了。
再隨著業務的發展，使用者交易量也跟著上去了，然而在乙個交易較為頻繁的時段，突然飈出來很多告警，機房內網路也不穩定，經過一排查，原來是網路裝置出現了問題，經過一小段時間折騰網路恢復了正常。然後小王心裡帶著忐忑地去翻看交易服務的日誌，發現出現了大量的報錯，還有不少報錯是顯式提示besteffors1pc在commit階段的錯誤！統計了一下，這次可不是手工能解決的問題了.....
小王寫了乙個批量資料修復程式，開始在生產跑了起來，但小王開始想，我用besteffor1pc是對的麼？
相信大家都聽過墨菲定律，就是說，你越擔心的事情，越有可能發生。
當然，這不符合我們程式設計師嚴謹的風格。我們萬事都要量化。小明同學的案例中，即使出現的概率是萬分之一，但當組合數量達到十萬個呢？達到百萬個呢？是不是就會變得經常出現了呢？小王同學的案例裡，因commit要走網路等io，這個整個過程要1-2毫秒不過分吧？當tps增多，這個1-2毫秒的危險視窗是不是就遍布整個時間範圍了呢？這個時候隨便發生下網路抖動，會怎樣呢？
寫程式有乙個特點就是，寫了一次，計算機會幫你執行無數遍，而你無需付出任何額外努力。但我們人工重複執行一件事情，卻要我們每次都付出精力與時間。
如果我們在寫**時放過的萬一經過的評估是：一年都不會發生一次的話，個人認為你是可以強行閉上眼睛不管這個萬一的。
但是誰能評估準呢？當發生了的時候，你要做的補救措施就是你當時遺漏的邏輯。當發生需要人工補救的情況時，所需付出的努力甚至要遠大於你當時完成這段邏輯付出的努力。
因此，小明和小王之後都懂得了 「出來行，遲早要還」的道理，不再放過任何乙個萬一。
那些把公司當家的程式設計師，後來怎麼樣了？
家是什麼？家是渴了有水喝，餓了有飯吃，冷了有衣穿。家是不管如何也會滿心歡喜的期待著要回去的地方。一句話 此心安處是吾家。每個家庭都這麼溫馨嗎？不見得，至少在公司這個大家庭中，並不是這樣。給大家講乙個故事 你有乙個溫馨的家，家裡每個人都各司其職，你的工作就是每天早上9到晚上9，一周6天，這樣不停的熬出...
程式設計師怎麼樣保證自己的程式沒有BUG
毫無疑問，程式設計師是善於思考問題的一族。乙個程式的編寫都是通過 思考 設計 編寫 除錯 測試以及執行這些基本的階段。但大部分程式設計師都有乙個問題，就是不太願意測試自己的 他們草草的調式完成以後就認為工作結束，測試那是測試人員的工作。按照理論上，如果 存在問題，那麼測試人員和最終的使用者肯定可以發...
程式設計師怎麼樣保證自己的程式沒有BUG
毫無疑問，程式設計師是善於思考問題的一族。乙個程式的編寫都是通過 思考 設計 編寫 除錯 測試以及執行這些基本的階段。但大部分程式設計師都有乙個問題，就是不太願意測試自己的 他們草草的調式完成以後就認為工作結束，測試那是測試人員的工作。按照理論上，如果 存在問題，那麼測試人員和最終的使用者肯定可以發...