不過……
有的人敲字灌水都錯字連篇，但是有人手寫幾十上百萬字的小說，隨便截一段都差不多能進語文課本……
所以，人與人還是有極大差別的。
不能因為“Linus也寫bug”甚至“Linus也寫過低級bug”，就認為“我寫個一百個整數里找最大值的簡單程序出三十個bug也是正常的”——初學者搞出這事，正常。
至于專業人員嘛……出一個都不正常。
不僅如此。
既然“寫長篇出bug正常，發條短信就那么十幾個字，錯一個都不應該”；那么我們把長篇拆開成若干章，一章只寫三千字呢？再把一章拆開成若干段，一段只寫數百個字呢？
這就是為何寫程序要先做模塊設計、然后再把模塊按職責拆分成類、類按功能拆分成函數、最后還要求一個函數不要超過一屏（大約80行）的原因了。
經過拆分之后，一個一個函數填寫實現、然后再一個一個函數做單元測試，測完再組合起來搞功能測試、集成測試……
這樣寫程序，當然還是無法杜絕bug出現；但出bug的機率就微乎其微了。
而且程序和長篇小說不同。
小說里的角色，尤其是主角和主要配角往往是貫穿始終的，這就使得小說章與章之間存在很多內部聯系；稍微搞不好就會導致前后失去呼應，比如主角一會兒傷在左手一會兒傷在右臂、或者前面挖個坑然后設個伏筆后面卻忘了用，等等。
但是在程序里面，不同模塊甚至不同函數之間，應該是毫無瓜葛的，每一個都可以摘出來獨立成庫——有瓜葛就說明用了全局變量或者靜態對象，或者通過參數或者約定等傳遞了過多的東西——這就叫“低耦合”。
做到了“低耦合”，你就可以把一個復雜的大程序當一組簡單的短文甚至短信寫。
這樣自然就很難出錯了。
當然了，有些情況下，程序邏輯非常復雜且無法拆分，也就是所謂“無法約分的復雜性”，這種代碼就必須端起十二分小心來，當然即便如此，bug出現率仍然要遠高于其他代碼。
一般來說，要把程序拆成“不可約分”的一組最小單元來寫。
這個“不可約分”就是術語說的“高內聚”：這段程序只做一件事，這件事已經沒法拆的更簡單了，只能把它們放在同一段代碼里一舉解決掉。
因此，寫程序時，事先的“謀劃”非常重要。
一個有經驗的資深工程師，可以在動手前就把一個復雜的大項目拆成一堆幾乎互不關聯的小程序，然后逐一實現它們、實現完再把它們組合起來就行了。
顯然，“謀劃”好了，一個程序的難度降低若干個數量級都是可能的。
說實話，在絕大部分能見到的軟件中，都是或多或少的有bug的……
只不過，第一開發可能沒想到，第二測試沒測到，第三用戶沒碰到，第四客服的反饋沒收到，那么——這就是一個“成熟穩健”的產品。
PS：留個言，你們是不是不喜歡看代碼相關的或者看不懂這些……說出來我以后少寫點，畢竟前期還是需要程序員的技術去賺錢的。當然你們的意見我也考慮一下。