在代碼的世界裡，是享受的，好多對編程感興趣的程序員，揮揮灑灑幾百行代碼，感覺不到累，反而倒是感覺很有成就感，很是享受，我想部分程序員網友有這種體會吧，然而，在代碼的世界裡，也有很多痛苦，比如，看別人的代碼，畢竟代碼只是一種語言，每個人的操作章法又是千差萬別，大部分人的思維可能都差不多，寫出的代碼大眾化，都能看得懂，但是也不排除有的人思維可能比較奇葩，不按什麼套路出牌，再加上遇到一些無註釋，無文檔，無人問的代碼，大牛看了也會忍不住鄒眉頭，近期就有一名程序員分享了他接手項目的一個情況。
據這名程序員網友所說，他是剛接手這個項目，打開後60%的代碼都曝黃線，if判斷寫的跟爬樓梯一樣，controller裡面各種邏輯判斷一個方法幾百行，這個項目的作者前幾天離職了，現在輪到他來維護這個項目了，讓他感覺很棘手，這名網友說好想把那個程序員拉過來暴揍一頓，這樣的情況他該怎麼辦，讓我們看看其他網友們都是怎麼看的吧！
網友一：不怕造飛機，就怕修飛機
上世是朵花：有這種體會，畢竟開發新的是按照自己的思路，算是在自己的舒適區內做事，維護別人代碼可能就需要走出自己的舒適區去了解其他人的思路了。
網友二：前人挖坑埋後人
上世是朵花：這話不仔細看還以為是：“前人挖坑後人埋”會以為說的是：“前人挖坑，後人填坑”，其實這名網友說的不是“後人埋”，而是“埋後人”，看這情況說的更嚴重了。
網友三：看著一個七千行的類，抱怨一番，默默加到了九千行
上世是朵花：這句話怎麼似曾相識啊，好像再哪裡見過似的，這樣的做法是逼迫系統一步步走向重構的邊緣啊！
網友四：事實就是這樣，先解決有無問題，優化？不存在的。老代碼更是這樣，不敢亂改邏輯只好添加新的分支判斷
上世是朵花：能夠理解，有時看是荒唐的做法也是無奈之舉。
網友五 ：ifelse完全是職業素養問題，和需求啥的，重構啥的沒關係，最簡單的拆方法都不懂
上世是朵花：沒錯，有的時候，我們雖然沒有能力去改觀整個項目的所有代碼，但是我們可以做到把我們自己的那一部分代碼寫的精緻一點，讓後人看著很舒服，從而也不會被罵。
網友六：我是接手一個PHP項目，還是用tp3搞的，真不敢直視，接口直接輸出html，看的我一愣一愣的
上世是朵花：可見這個項目比較古老了，這樣不友好的寫法的確有，並且更讓人覺得煩惱的是，有的代碼雖然很遭，但是業務很火，代碼還在高頻使用，修改起來也必須很慎重。
華為員工：我在面對一個9014行的.c文件
上世是朵花：家家都有一本難唸的經啊，各種各樣的高難度維護。
網友八：這就是代碼，為什麼平均兩年一重構的原因，不重構實在不行了
上世是朵花：沒錯，如果沒有良好的代碼管理制度，最後都可能走向重構的邊緣。
每種不好維護的項目代碼，都是從第一行代碼寫起的，都不是一開始是這樣的，前期如果不太注重代碼的規範與質量，就已經打下了不好的基礎，後人只能在這個基礎上一步步累積，最後歪樓。這種現象的產生，我個人認為責任主要不在一線程序員們，比如有的程序員很講究代碼質量，代碼寫的很精緻，但是他接手了一個地基沒打好的項目，他也很無奈，只能在這個不好的地基上繼續開發，這個原因主要在於技術管理者，技術管理者除了負責技術方案制定，項目的跟進之外，代碼流程的管理也是相當重要的，制定代碼規範，讓所有人寫的代碼是一個風格，統一大家的思維，讓整個項目的代碼看著就像一個人寫的似的，並且有完整詳細的代碼註釋與及時同步的項目文檔，這樣的話，相信不論是多少屆人員的更替，代碼看起來仍然很舒服，從程序員網友們的評論就可以看出有相當一部分公司存在著代碼管理的問題，因此，作為公司的一名技術管理者，在這方面要做的事情還是任重而道遠啊！
以上所有圖片均來之互聯網
大家好，我是“上世是朵花”。如果你有什麼好的看法或者觀點可以在評論區展現你的才華，互動交流，如果想進一步瞭解我，那就關注我吧！
閱讀更多 上世是朵花 的文章
