假如有一個專案在客戶的手裡執行的很穩定，也比較滿足客戶提出的需求，後期會根據客戶的要求在新增一些新的功能，但是把專案程式碼拿到手裡之後我還是忍不住要重構其中的程式碼。

專案需要重構的原因不外乎有以下幾種原因：

一、沒有實現客戶的所要求的的功能
這個是主要的原因，開發的軟體執行的再好，如果沒有達到客戶的要求就等於做了無用功，這個專案也是沒有價值的。還需要根據客戶的需求繼續新增修改程式碼以實現客戶要求的功能。這裡的重構不但指的是修改之前的程式碼，還指新增程式碼以實現功能。

二、不能很好的適應新的需求變化
任何一個專案都不會是一個人開發的，是需要一個團隊通力協作完成的。每個人都會負責這個專案的某一部分，但是如果其中有人由於一些原因調離這個專案，那麼專案分工就會重新安排。當客戶新的需求來時，會由其他成員來完成這部分功能，但是他會發現上一個同事寫的程式碼結構比較混亂，程式碼風格變數定義非常的隨意，簡直是無從下手，更要命的是裡面的程式碼具有很強的耦合性，不知道從哪修改，彷彿就是一個地雷有很多引信一樣，修改完成一個地方還有另外三個地方程式碼與之相關聯。任何一個新的需求的新增需要修改無數個檔案，呼叫多個函式才可以實現，對任何一個程式設計師來時簡直就是噩夢。

三、無法通過程式碼來進行溝通
一個具有良好的程式碼風格的軟體專案對程式設計師來時就是一種福音，對該模組不熟悉的人來說可以很好的閱讀這些程式碼並且很快的進入狀態。若程式碼結構混亂程式碼、風格各異，對於任何一個程式設計師來說都是一種災難。一個雖然執行穩定但是閱讀起來很困難的程式碼也是有必要重構的。

重構就好比做飯後對廚房的清理工作。第一次沒有清理用餐速度回快一些。但是由於你們對鍋碗進行清理，第二次做飯的時候，準備工作就要長一些。這會促使你做一些清理工作。但是你如果錯過清理工作，今天你也可能回用餐快一些，但是髒亂會一天天的積累起來，到最後你會話費大量的時間去找碗或者烹飪器具。艱難的洗淨上面積累的很厚的食物殘餘。飯是天天吃的，忽略清潔工作並不能真正加快做飯的速度。

重構就是每天清潔你的程式碼，我想通過最小的努力實現系統的擴充套件和修改，想要具有這種能力，最重要的就是保持程式碼的整潔和結構的清晰。