作為一名程式設計師可能最不願意遇到的事情就是接手一個“爛攤子”。半路接手專案的原因有很多，有的是專案進展到一半，核心開發人員整體調離，有的原因是開發人員離職等。而所謂的“爛攤子”往往有一些顯著的特點，比如沒有需求分析文件、沒有流程圖、程式碼沒有註釋、邏輯混亂、bug比功能多等等。

從事軟體程式設計以來，我也曾經半路接手過不少專案，有的程式碼寫的非常工整，尤其是Java專案，大部分都非常規整，這是Java語言自身的特點。

但是，也有的Java專案寫的並不規整，需要耗費比較長的時間才能釐清邏輯關係，在接手這樣的專案時，往往要做好以下幾個方面的事情：

第一，對程式碼的整體結構進行分割。再亂的程式碼也是有模組（包）的，這是Java語言的特點所決定的，所以就可以按照功能模組進行切割，分別整理並加上標註。

第二，封裝核心部分程式碼。把已經完成的沒有邏輯問題的程式碼給整體封裝出來，釐清其中的邏輯關係和設計思路，尤其是其中的介面部分。因為後續的開發工作要在這個基礎上進行，所以要把這部分內容搞清楚。

第三，逐步處理問題程式碼。把未完成的部分和有bug的部分進行依此整理，最好是找出一個功能主線，然後一步一步的處理。當處理到這個階段的時候，基本上這個“爛攤子”已經差不多快處理完了。

在處理別人程式碼的時候一定要把註釋加全，越詳細越好，這樣再回頭檢視的時候會節省很多時間。有的程式碼一看就知道是什麼思路的就可以不用寫的那麼詳細，因為現在的Java程式碼在很多功能的設計上，思路還是比較統一的。

如果有Java開發方面的問題，也可以諮詢我。

那要看專案規模以及到底有多爛，如果功能不超過十幾個且業務邏輯不復雜的話，可以嘗試按照模組重構；如果專案龐大並且真的是夠爛的話，讓他繼續爛下去可能是最好的選擇，千萬別琢磨重構什麼的，沒有大量的人力、物力、財力支撐，你會把自己玩到跳樓。所以讓它爛下去，對修改的功能、程式碼嚴格把關，確保不出大的、嚴重的、毀滅性的問題，支撐到有投入可以進行系統升級或者更新換代，你的使命也就完成了。