老讀者都知道的，我沒干過什么大事，無非就是敲敲代碼、寫寫文章，還有就是及時吃飯、睡覺、打豆豆，
這不，就有個哥們看不慣我了，再見之后還要撂下這句狠話：“你這種人是干不了大事的，”
好吧，我承認，都是我的錯！我真沒想過要干什么大事，我覺得打打雜，掃掃地挺好的，我估計我來到這個世界上的時候，父母也沒對我抱太大的期望，否則清華北大沒錄取我這事會把他們氣瘋掉的，事實上，即便我只考了個大專，他們仍然沒有拋棄我、放棄我，
不知道大家有沒有看過《西西里島的美麗傳說》，漂亮的女主人公（女神）被生活無情的摧殘，但最后，她仍然對那些欺辱過她的女人報以純潔的微笑，
我對這位貶低我的哥們也報以微笑（??），快，看我的表情，純潔吧？那為什么我還要提這件事呢？難道不是因為我小肚雞腸、耿耿于懷？還真不是的，我只是想引（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！如果大家想要第一時間看到二哥更新的文章，可以掃描下方的二維碼，關注我的公眾號，我們下篇文章見！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/45238.html
標籤：其他
上一篇：如何在寒冬中找到好作業？