楊若楓
辭職的人留下一堆寫的比較爛的代碼，這種事情在十幾年的編程生涯中遇到了好幾次。即使代碼再爛在沒有預留充足的時間情況下，也不會輕易的改動，在有限的時間內先把能處理的邏輯給修正下，想要大塊的修復還需要時間充足的狀態下進行重構，重構是存在風險的，至少還需要花費很多時間測試功能的穩定性，目前國內的很多公司的軟件都存在這種情況，由於趕項目的原因如果是代碼水平一般的程序員很容易寫出一些很難維護的代碼，關鍵這個代碼把對應的功能還實現了，只是從代碼的可讀性以及維護性上差的太遠，如果寫代碼還一直呆在公司，這個模塊出現問題或者增加新的功能還在可控的範圍，如果這個人離職就悲劇了，恨得不得了，還要堅持去用。
曾經在一個美國上市公司，有一堆底層音視頻解碼代碼被很多人稱之為禁區，不敢碰裡面的代碼，因為當初寫代碼的人已經走了很多年了，曾經有無數的技術高手想把這個坑給填了，但由於平時的工期特別緊張，就成就了一種無人能碰的垃圾代碼，直到離開公司的時候還是這種狀態，垃圾代碼的形成是由多個因素造成，一是工期太短，二是寫代碼的水平有限。其實每個程序員都是從寫初級代碼也就是垃圾代碼一步步走過來的，只不過相對來講不停的在垃圾代碼上進行升級一步步變成優秀的代碼，所以一個程序員基本素質需要基本的代碼重構的意識，不停的在錯誤中提升自身能力。
作為一個合格的程序員，規避不了垃圾代碼，只要自己負責這個模塊就有責任把這個事情做好，可以循序漸進的去重構，然後在新的版本發佈的時候帶入進去，一個標準的程序員首先要對自己的代碼負責到底，代碼是一個程序員的臉面，有很多程序員把自己的代碼維護特別細心，代碼就是自己的臉面，生怕因為代碼質量不好，影響自己的形象。一個程序員都不懂得維護自己的代碼形象，給自己的定位已經確定了，優秀的程序員從來都是一手高質量的代碼。
希望能幫到你。
大學生編程指南
這種情況我在參加工作沒多久就遇到過一次，沒有文檔，代碼中拼音和英文混合使用，註釋寫的一塌糊塗，有的模塊壓根就沒有註釋，有的模塊還是直接拷貝的，怎麼發現的？註釋都是英文，原作者還在上面立著呢！
當時的心情鬱悶到極點，我當時就想:我這程序員生涯才剛開始，怎麼這麼倒黴？難道程序員生涯要結束了麼？我當時都有換個研究室的想法了。
好在我堅持了下來，我把所有代碼重新導了出來，使用最原始的工具editplus一個文件一個文件測試，重新寫註釋，其實一週時間就把結構釐清了，有的時候看似困難的事情，其實沒那麼困難。
這個過程中我也厚著臉皮給原作者打過幾次電話，也起到了一些作用，至少那些迷一般的設計能有人給你解釋一下，從此以後我沒再遇到這麼棘手的事，希望我的回答對你有所幫助。
IT人劉俊明
首先，接手的你心裡肯定一萬匹草泥馬，在這裡先深表同情。
為了接下來的工作，我覺得你也只能硬著頭皮去看代碼了，但個人覺得如果你能從中改善代碼，倒也是一個學習的機會，與其去抱怨其代碼，還不如從中進行改善，不僅能熟悉項目的業務邏輯，也能提升一下自己的編程能力，但這個需要一定的時間，就看你項目趕不趕，趕的話只能是看一步走一步，這個過程是有點痛苦吧，但一步一步來吧。
我也是一個程序員，繼承過一些別人寫的代碼，坑就有的，有時候一不注意自己就掉進去，心裡一萬匹草泥馬，但又能怎樣，現在維護項目的是自己，所以有時候在開發過程中會注意，將一些無用代碼刪除，提取一些可以複用的代碼，但這要在熟悉那塊業務的基礎上去做修改，儘量也別給自己挖坑跳。
總之，做程序猿這行是不容易，除了不斷的需求加班，還要擔心被別人代碼坑，但既然選擇了當程序猿，就要從中去找到一些學習進步的點來提高自己，爭取不要做那個寫垃圾代碼的人，哈哈~
百佳雜談
代碼沒註釋都還好，都是英文單詞，用有意義的單詞命名，少用縮寫。可是英文單詞都寫錯了，重申過類、文件、表名哪些用單數哪些用複數，還搞錯。類名搞那麼長做什麼，和命名空間重複去掉。符號後面能不能用空格？語句塊之間能不能放空行？能不能別在公共模板裡亂加代碼，你讓別的模塊怎麼用？代碼一團糟，邏輯也一堆一堆問題
大懶貓科技
接手到垃圾代碼要看一下是否需要你修改這裡的代碼，因為如果運行比較穩定，可能也不會讓你修改了。如果需要修改就要看有沒有接口文檔，和代碼註釋了。 如果什麼都沒有，代碼邏輯也比較複雜，恭喜你中獎了。你要知道這裡的代碼具體是幹什麼的，處理的業務是什麼。然後在哪裡修改不影響原來的邏輯，
高手從代碼上也是可以看出代碼邏輯的，只不過比較費事。實在不行，推倒重新寫也是可以的
