一名程式設計師剛剛入職一家公司，就遇到了一件糟心事：剛剛接手了一個專案，開啟後60%的程式碼都曝黃線，if判斷寫的跟爬樓梯一樣，controller裡面各種邏輯判斷一個方法幾百行，這個專案的同事前幾天離職了，工作了7年！我該怎麼辦。

很快，這樣的吐槽引起了同行們的口誅筆伐，認為上任程式設計師太缺德，這不是坑別人嗎，樓主對此也表示憤慨不已：好想把他拉過來暴揍一頓。

有同行如此評價：看著一個七千行的類，抱怨一番，默默加到了九千行；前人挖坑埋後人；我在面對一個9014行的.c檔案；事實就是這樣，先解決有無問題，優化？不存在的，老程式碼更是這樣，不敢亂改邏輯只好新增新的分支判斷；這就是程式碼，為什麼平均兩年一重構的原因，不重構實在不行了。

如果有想要學習web前端的小夥伴，可來我們的web前端學習扣裙哦：571019044裡面贈送web前端系列教學視訊和資料!小編也是從事了6年web前端開發的全棧工程師，歡迎初學者和想要進階的同學進來一起學習。

還有同行認為這完全是職業素養問題：ifelse完全是職業素養問題，和需求啥的，重構啥的沒關係，最簡單的拆方法都不懂；承認程式碼爛有那麼難嗎，寫這種垃圾程式碼的一般自己意識不到，意識到了反而會注意，這種程式碼需求一改就到處改還bug多。

還有同行講述了同病相憐的遭遇：我是接手一個PHP專案，還是用tp3搞的，真不敢直視，介面直接輸出html，看的我一愣一愣的；接了一個12年畢業的程式設計師留下的專案，工作六年多了吧，原先是做C的，然後又寫前端，最後又轉的JAVA，他的程式碼就和你說的差不多，還在control裡以responseboy的方式返回拼接拼接動態html，他的桌子上有一本JAVA經典模組大全，就是學那個的。

不過也有程式設計師進行了客觀的分析：一般很多功能實現有好多種方案，越好的設計和方案大部分工作量越大，這種最好的方案往往最先pass，然後選最小改造最快實現，就產生了一堆別人覺得爛的程式碼。