我是一名coder，俗稱碼農

每個程式設計師都有自己的風格，風格的不同造成閱讀的難易，有的程式設計師有潔癖，寫程式碼非常規範，包括什麼時候縮排，縮排多少，以及註釋都非常完整，這樣的程式碼閱讀起來就會非常舒服，換句話說就是樂於閱讀，有的程式的寫程式碼則非常隨性，想在那裡換行就換行，想起來就寫幾行註釋（當然前提是沒有程式碼review的前提下），對於這樣的程式碼，我們是非常不願意去動的，寧可自己重新寫一遍。

話說回來，不願意改別人的bug，並不代表就不用改，專案就是這樣，每個人分工不同，我們總會遇到一些需要改別人程式碼的情況，所以在工作中需要培養閱讀程式碼的能力，你只有讀懂了別人的程式碼才知道如何去改，當然我們也要養成寫優秀程式碼的能力，目的就是便於後來人看懂和修改。

還有一點不願意改別人的原因，可能是這個bug只是一部分程式碼，改完不知道會出現什麼影響，所以不願意改。

改bug是程式日常工作的一部分，所以不存在願不願意，只存在要不要改，bug出現必須得改，不願意也要改，但是在開發中還是應該遵循一些開發原則的，整個團隊如果都遵循的話，bug改起來也會輕鬆一些

開發過程中合理的利用上述原則，就算有bug改起來也不會很困的，如果沒有遵循這些原則的話，改一個bug就有可能牽一髮而動全身

程式設計師最不喜歡接手不規範得程式碼和bug，即使是出於職業的習慣，也是很難克服，做了十幾年程式接手前任得程式碼都會有一種不習慣的感覺，其實有時候也會容易造成一種錯覺，有的程式設計師寫過的程式碼讓人看著非常舒服，程式碼規範而且還配套有單元測試得程式碼，更重要的還有技術說明文件，但更多的是硬生生的程式碼，沒有註釋看起來特別得麻煩。

但大家都會不由自主的相信開源社群的程式碼，即使裡面有問題也會帶著一種寬大仁愛的心態去對待，這屬於一種慣性思維。畢竟能提交到開源社群的程式碼，在編碼規範方面肯定比平時寫的程式碼稽核更加嚴格規範一些，既然是程式碼就存在出問題的可能性，之前從谷歌拿到一份開源的程式碼在上面做東西，發現有一個重大得記憶體洩露問題，最後也是因為程式碼寫的不嚴謹造成，所以只要是人寫的程式碼，就可能存在不確定性。

寫程式碼的時間一般來講都比較短，大部分時間都還都是除錯或者前期調研，程式設計得大部分時間不是寫程式碼，很多國內的公司在前期調研的時間都壓縮的比較短，程式碼寫的也比較著急，所以程式碼出問題比較多，這才是程式設計師不接手前任程式碼的根本所在，而且普遍的週期壓縮的比較短，整體來講沒有時間去做程式碼消化整合，導致程式碼數量越來越多，但是越來越難維護，所以後來接手的人會十分的頭疼，不自然的就會有一種牴觸的心理。