@程序員，認可吧，都是你的錯！

老讀者都知道的，我沒幹過什麼大事，無非就是敲敲代碼、寫寫文章。還有就是及時吃飯、睡覺、打豆豆。

這不，就有個哥們看不慣我了，再見以後還要撂下這句狠話：「你這種人是幹不了大事的。」

好吧，我認可，都是個人錯！我真沒想過要幹什麼大事。我以爲打打雜，掃掃地挺好的。我估計我來到這個世界上的時候，父母也沒對我抱太大的指望，不然清華北大沒錄取我這事會把他們氣瘋掉的。事實上，即使我只考了個大專，他們仍然沒有拋棄我、放棄我。

不知道你們有沒有看過《西西里島的美麗傳說》，漂亮的女主人公（女神）被生活無情的摧殘，但最後，她仍然對那些欺辱過她的女人報以純潔的微笑。

我對這位貶低個人哥們也報以微笑（😊），快，看個人表情，純潔吧？那爲何我還要提這件事呢？難道不是由於我小肚雞腸、耿耿於懷？還真不是的，我只是想引（che）出本篇文章的主題：程序員，認可吧，都是你的錯！

（看我耍了多麼大的心機）

不知道你們有沒有過這樣的體驗：明明程序在本地測試經過，運行的好好的；但不知道爲何在正式環境下就恰恰有問題，不只見了鬼，還奇了怪！

咱們找啊找，費了老大的勁兒，可仍是找不到緣由。問題把咱們折騰得夠嗆，因而咱們只好攤攤手，搖搖頭，嘆口氣，很難爲情地扔下一句狠話：「這特麼確定是環境有問題。」

是的，對於大多數的項目來講，代碼裏經常混雜着不少東西：團隊其餘成員的代碼、第三方類庫、數據庫連接、網絡通訊等等，以及程序運行的平臺環境。

對於大多數的程序員來講，不得不面對的一個沉重的事實就是，工做中用的電腦是 Windows 操做系統，而項目正式部署的環境是 Linux 操做系統。跨平臺之間的差別，有的時候能把咱們搞崩潰。

早年間我作過一個大宗期貨交易平臺，某一家客戶爲服務器端提供的環境是 Windows，某一家客戶提供的是 Linux。代碼打成 的 war 包幾乎沒有任何差異，惟一差異就是幾個配置參數不同。Linux 的運行的好好的，但 Windows 就很不幸了，Web 版的首頁打開幾乎要一分鐘之久，那種什麼事也幹不了的等待幾乎能把全部的用戶殺死在搖籃中。

當時我很傻很天真，腦子也沒怎麼動，心思全放在如何減輕首頁加載的資源上面。把 CSS 壓縮、把 JavaScript 壓縮、減小請求的訪問數目、圖片懶加載、緩存、減輕數據庫的壓力等等，我能想到的辦法都試了試，但幾乎於事無補——首頁的訪問速度沒有什麼明顯的改善。

通過一週時間的琢磨，我打算放棄了，差點憤怒地把鍵盤砸壞（握緊雙拳，用力地砸下去）——你們有過那種要發泄情緒的時候嗎？

很無助，就像少年派和一隻吃人的老虎飄蕩在同一條救生船上同樣的無助！

這特麼確定是環境有問題。

但我決定忍住，因而我又花了一週的時間研究了不少其餘性能優化的方案，雖然最後仍然沒起多大用處。沒辦法，我終於妥協了。我開始和客戶溝通，問他們能不能提供一個 Linux 環境的服務器。你們猜客戶怎麼說？他們說不用再提供，只須要一鍵切換就能夠把 Windows 切換成 Linux，雲服務器都有這種功能。what？

而後，我火燒眉毛地從新安裝了 Linux 版的 JDK、MySQL、Tomcat，把以前在 Windows 上運行的 war 包往上面一扔，而後啓動 Tomcat，你們猜結果怎麼樣？

首頁訪問速度和另一臺 Linux 的幾乎差很少，幾秒鐘的事兒。當時我那個氣急敗壞的樣子，就好像地主家生了個傻兒子同樣。

今後，我就篤定一條：只要問題搞不定，就賴環境，就賴第三方！

後來，我在作支付寶支付的時候遇到了另一個奇怪的問題，用戶的錢已經從平臺的支付寶帳戶上划走了，但咱們平臺的資金帳戶就是沒有更新。

我當時就懷疑是支付寶的第三方 jar 包出了問題。由於系統一直運行的挺穩定的，我也沒有對支付寶接口作任何的修改。

我就憤憤不平地提交了工單，質問支付寶的小哥：「大家支付寶接口是否是有問題，爲何支付寶上的帳戶資金已經劃轉了，卻沒有給我返回通知，致使咱們平臺上的資金帳戶沒有更新？」

來來回回和小哥溝通了幾回，他態度一直挺淡定、挺友好的，我卻一次又一次的心虛：問題找出來了，是我不經意間修改了一行代碼致使收到的通知被漏掉了（居然忘了比較代碼版本）。

當時本身那個灰頭土臉的樣子，真的是想找個地洞藏起來，羞愧難當啊！我至今還清楚地記得我最後回覆的那句話：「對不起，是我錯怪支付寶了。小哥，請見諒。」十足的勇氣。

不知道那位小哥當時收到我這句真誠的道歉時會怎樣想，會不會內心惡狠狠地罵一句：「又遇到一個傻X，當咱們支付寶是過家家的啊。」

在我這十年程序生涯中，遇到過的 bug 多到像秋天裏的蚊子同樣，數也數不清，補丁打也打不完。我總結出來一條真理：認可吧，都是你的錯，問題就出在你本身寫的代碼裏。只有抱着這種心態，才能在最快的時間內找出問題的解決辦法。

從統計學的角度來看，軟件中的故障通常都是人爲引發的，例外的狀況少之又少。這一點在《代碼大全》這本書中也曾被提到過，儘管統計的年代已經離咱們很遙遠了，但仍然具備借鑑意義。

經過 1973 年和 1984 年的兩次研究代表，全部上報的錯誤中，大約 95% 是由程序員引發的，2% 是由系統軟件（編譯器和操做系統）形成的，2% 是由其餘軟件（第三方類庫）形成的，1% 是由硬件形成的。

就目前的狀況來看，系統軟件、第三方類庫和硬件都愈來愈趨完善，那麼相對來講，程序員肩負的責任就更大了。這大概也是程序員動不動被拿來祭天的緣由了（呵呵）。

淡定淡定，就讓咱們作一個謙遜的程序員吧，遇到問題就堅決果斷地從本身的代碼找起，哪怕最後肯定問題真的不是本身引發的，那麼也爲咱們打足了底氣，留下了確鑿的證據。從另一方面來講，這是防止別人甩鍋的最好辦法。

「嘿，哥們，這是個人錯，就讓我來把問題弄個水落石出吧！」就像我對待文章開頭提到的那個抨擊個人哥們來講，你們並不會以爲我不夠硬氣，反而只會以爲那哥們很可愛，而我很風度翩翩。

---

好了各位讀者朋友們，以上就是本文的所有內容了。能看到這裏的都是最優秀的程序員，二哥必需要伸出大拇指爲你點個贊👍。若是以爲不過癮，還想看到更多，我再給你們推薦幾篇。

程序員的遮羞布：這個需求技術上沒法實現
@程序員，別再迷戀多線程工做了
@程序員，請掌握這些核心生存技能

平常操做來了！若是以爲這篇文章有點用的話，求點贊，明人不說暗話，我喜歡這種被你們夥寵愛的感受。

one more thing！若是你們想要第一時間看到二哥更新的文章，能夠掃描下方的二維碼，關注個人公衆號。咱們下篇文章見！