我個人理解代碼的好壞，應該從2方面來說，其中一方面是與機器相關的，那就是代碼是高效的，高性能的，沒有冗餘的代碼，沒法再減去一行。另一方面就是與人相關，那就是從代碼的書寫規範上有著良好的習慣與素養，有著簡潔的註釋，讓人一看便懂，很容易維護，讓人看了能夠賞心悅目，這樣的代碼都是程序員們都歡迎的。
因此作為一名程序員，要想做到受同事們歡迎，首先最起碼的就是要寫出受人歡迎的代碼，只有代碼受人歡迎，才能讓人歡迎不是嗎？如果你經常寫出讓人頭疼的代碼，我想同事們如果遭遇一次你的代碼，以後很難做到對你和顏悅色了，接下來，就讓我們看看一名網友分享出的一段人神共憤的代碼吧！
先不看代碼的具體內容，就說這架勢，一下子是不是就把人給嚇住了，你有沒有同樣的感受呢？我想如果沒有定力的人，遇見這樣的代碼就會一下子不淡定了，更不用說慢慢的去梳理其中的邏輯了。
針對這樣的情況，特意問了一名網友，如果這樣的代碼交給你維護，你會怎麼做，他說了一句話特別耐人尋味，他說，既然交給我了，那我就繼續維護唄，我會繼續往上面再加一層啊，針對他這樣的態度我還真說不出他是積極的態度，還是消極的態度，如果說他消極吧，人家是很樂意地接受維護這樣的代碼，可是針對他這樣的回答，覺得又有點不對勁，怎麼能那麼不負責任，繼續往上面添加，難道不應該是梳理出邏輯，好好把代碼再調整一下嗎？
不過再仔細想一想，現實中的確是這樣，遇見這樣的代碼，好多人也不願意冒險去重構，只能是硬著頭皮去梳理其中的邏輯，然後在合適的地方在追加一句新的邏輯，僅此而已，這應該是80%的程序員會選擇的做法吧。
既然是這樣，讓我們再回過頭看看上面的代碼，這時你有可能會有這樣一種想法，那就是上面這段代碼可能不是一個人的“傑作”，可能是日積月累的產物，比如最初這段代碼只有三層的邏輯，後來產品需求變化了，要求另一個程序員去維護，這個程序員就繼續往上面追加一層邏輯（因為這是80%的程序員會做出的選擇呀），然後在接下來數月，產品的需求經過幾次變更，人員也出現幾次更替，幾屆程序員經過幾次邏輯追加，然後就變成了上面這樣一段代碼。
其實有的時候一個事情的結果是錯的，但是過程中的每一步感覺都沒什麼錯，都是當時最正確的選擇，大家覺得有沒有這個意思，當我們看到一個荒唐的現象時也沒必要急於去批判它，應該去想想它產生的原因，能夠從根源處發現原因，也許就會理解了，如果自己是一個負責人的程序員，那就不以惡小而為之，讓這個錯誤止於自己這兒，這樣的做法不僅對自己有利，也讓其他人受益不是麼？
以上所有圖片均來自互聯網
大家好，我是“上世是朵花”。如果你有什麼好的看法或者觀點可以在評論區展現你的才華，互動交流，如果想進一步瞭解我，那就關注我吧！
閱讀更多 上世是朵花 的文章
