辭職的人留下一堆寫的比較爛的程式碼，這種事情在十幾年的程式設計生涯中遇到了好幾次。即使程式碼再爛在沒有預留充足的時間情況下，也不會輕易的改動，在有限的時間內先把能處理的邏輯給修正下，想要大塊的修復還需要時間充足的狀態下進行重構，重構是存在風險的，至少還需要花費很多時間測試功能的穩定性，目前國內的很多公司的軟體都存在這種情況，由於趕專案的原因如果是程式碼水平一般的程式設計師很容易寫出一些很難維護的程式碼，關鍵這個程式碼把對應的功能還實現了，只是從程式碼的可讀性以及維護性上差的太遠，如果寫程式碼還一直呆在公司，這個模組出現問題或者增加新的功能還在可控的範圍，如果這個人離職就悲劇了，恨得不得了，還要堅持去用。

曾經在一個美國上市公司，有一堆底層音影片解碼程式碼被很多人稱之為禁區，不敢碰裡面的程式碼，因為當初寫程式碼的人已經走了很多年了，曾經有無數的技術高手想把這個坑給填了，但由於平時的工期特別緊張，就成就了一種無人能碰的垃圾程式碼，直到離開公司的時候還是這種狀態，垃圾程式碼的形成是由多個因素造成，一是工期太短，二是寫程式碼的水平有限。其實每個程式設計師都是從寫初級程式碼也就是垃圾程式碼一步步走過來的，只不過相對來講不停的在垃圾程式碼上進行升級一步步變成優秀的程式碼，所以一個程式設計師基本素質需要基本的程式碼重構的意識，不停的在錯誤中提升自身能力。

作為一個合格的程式設計師，規避不了垃圾程式碼，只要自己負責這個模組就有責任把這個事情做好，可以循序漸進的去重構，然後在新的版本釋出的時候帶入進去，一個標準的程式設計師首先要對自己的程式碼負責到底，程式碼是一個程式設計師的臉面，有很多程式設計師把自己的程式碼維護特別細心，程式碼就是自己的臉面，生怕因為程式碼質量不好，影響自己的形象。一個程式設計師都不懂得維護自己的程式碼形象，給自己的定位已經確定了，優秀的程式設計師從來都是一手高質量的程式碼。

程式碼沒註釋都還好，都是英文單詞，用有意義的單詞命名，少用縮寫。可是英文單詞都寫錯了，重申過類、檔案、表名哪些用單數哪些用複數，還搞錯。類名搞那麼長做什麼，和名稱空間重複去掉。符號後面能不能用空格？語句塊之間能不能放空行？能不能別在公共模板裡亂加程式碼，你讓別的模組怎麼用？程式碼一團糟，邏輯也一堆一堆問題

接手到垃圾程式碼要看一下是否需要你修改這裡的程式碼，因為如果執行比較穩定，可能也不會讓你修改了。如果需要修改就要看有沒有介面文件，和程式碼註釋了。 如果什麼都沒有，程式碼邏輯也比較複雜，恭喜你中獎了。你要知道這裡的程式碼具體是幹什麼的，處理的業務是什麼。然後在哪裡修改不影響原來的邏輯，

高手從程式碼上也是可以看出程式碼邏輯的，只不過比較費事。實在不行，推倒重新寫也是可以的

首先，接手的你心裡肯定一萬匹草泥馬，在這裡先深表同情。

為了接下來的工作，我覺得你也只能硬著頭皮去看程式碼了，但個人覺得如果你能從中改善程式碼，倒也是一個學習的機會，與其去抱怨其程式碼，還不如從中進行改善，不僅能熟悉專案的業務邏輯，也能提升一下自己的程式設計能力，但這個需要一定的時間，就看你專案趕不趕，趕的話只能是看一步走一步，這個過程是有點痛苦吧，但一步一步來吧。

我也是一個程式設計師，繼承過一些別人寫的程式碼，坑就有的，有時候一不注意自己就掉進去，心裡一萬匹草泥馬，但又能怎樣，現在維護專案的是自己，所以有時候在開發過程中會注意，將一些無用程式碼刪除，提取一些可以複用的程式碼，但這要在熟悉那塊業務的基礎上去做修改，儘量也別給自己挖坑跳。

總之，做程式猿這行是不容易，除了不斷的需求加班，還要擔心被別人程式碼坑，但既然選擇了當程式猿，就要從中去找到一些學習進步的點來提高自己，爭取不要做那個寫垃圾程式碼的人，哈哈~

我遇到過很多次，同事離職或者調崗，我直接去接手一個模組甚至一個專案。

甚至在上一家單位，我在專案上線前一兩週的時候接手一個模組，但當時該功能的SQL語句在準生產環境上無法執行（執行時間很長，最終超時）。

好在我花了不到一週的時間對程式碼進行了最佳化，勉強趕在了規定的時間上線。

如果單位安排了工作交接，那麼一定要充分利用這段交接的時間。先了解這個功能模組的業務流程、操作過程，這個很重要。工作交接不是上來就講程式碼，而是你要告訴我這個模組是做什麼用的、有哪些操作、提供了哪些介面、和周邊系統怎麼互動等等。

在交接的過程中，我一般都會上午交接，主要是對方講；下午我去看系統、看程式碼，有問題主動問。

也有很多時候，交接的時間很短，甚至沒有交接、沒有文件、沒有註釋，只有一堆程式碼。這時候先把專案跑取來，儘可能的找相關人員瞭解操作流程（比如測試人員），熟悉業務流程，再打斷點一步一步的跟程式碼。

如果有新需求需要開發，這時候就要慎重了，在實在拿不準的情況下，儘可能的寫一段新的邏輯；當然，從長遠的角度看，還是要了解老程式碼，重構老程式碼。

總之，作為一名程式設計師，難免要接手老系統、接手別人的程式碼，對“爛程式碼”進行解讀和重構，也是程式設計師的必修課之一。