程式出現bug是必然出現的情況還是程式猿水平有限導致的？
阿新 • • 發佈：2019-01-09
- 既然“寫長篇出bug正常，發條簡訊就那麼十幾個字，錯一個都不應該”；那麼我們把長篇拆開成若干章，一章只寫3000字呢？再把一章拆開成若干段，一段只寫數百個字呢？
- 低階bug：100%是程式猿的鍋，不仔細看需求文件和設計文件導致實現結果偏離需求，寫的時候不認真各種說出來丟人的拼寫錯誤，寫新程式碼不知道考慮對已有程式碼的影響上手就胡來，寫完程式碼自己都不自測一下就提QA。這都是沒有職業修養的表現，QA測出bug你不背鍋誰背鍋！
- 業務邏輯bug：通常源自需求溝通出現問題，這往往是所有人同時出問題，而不是某一個地方出現問題。第一環節是需求方自己說不清楚，第二環節是需求分析師沒理解需求，第三環節是設計師沒有動腦子還沒做設計評審，第四環節是不跟需求方做需求設計確認。
- 深度邏輯bug：不能把鍋推給任何一個人，設計、開發、QA全都有責任，但這種bugQA通常根本測不出來，一般要上線穩定執行好久才被發現，而且會相當難解決。
- 效能缺陷bug：逐層背鍋吧。開發能力不足，原子功能執行效率低下；設計不合理，高效能原子功能組合成模組效能低下；架構不合理，高效能模組聯合成整個系統死活是玩不轉。
- bug數量和系統複雜度和開發時長成正比，程式設計師對系統的熟悉程度成反比。水平再高的程式設計師扔到一個非常複雜開發了十幾年的系統裡，照樣容易出bug。
- 人類不是個很靠譜的東西，總會有隨機錯誤，即使打字錄入這麼簡單的事情都有1-3%的錯字，何況寫原始碼這種比打字難得多的事情。在研發成本投入足夠，開發商也重視質量的前提下，bug數量主要取決於測試，而測試是否充分主要是需求決定的。也許會有個別程式設計師水平欠佳，但是在測試充分的時候他們很快會被發現。
- 上古時期，絕大部分書籍後面都附著幾頁『勘誤表』，告訴你某頁某行有個錯別字，正確的應該是什麼。
- 你踩到屎的時候，是怪自己不小心，還是怪那個隨地拉屎的人？如果一個程式設計師bug很少，那大概是他沒有遇到那些屎一樣的需求！！！
- bug就是程式設計師的成長催化劑，遇到了，搞懂了成長了，以後再寫程式碼就會有更多的提前預見。然後bug逐漸減少。要說bug～程式設計師天生不就是來創造bug然後解決bug的嗎?