先從接觸過的幾個老專案經歷來談談，對於老專案來說，大家在初步接觸的過程中，大多總是抱著牴觸的情緒，甚至有些是蔑視。總喜歡對以前的程式碼挑出一大堆的問題，接著就開始抱怨程式碼、抱怨以前的開發人員，經過一段時間鬱悶的抱怨階段後，處於職業的責任心，就很想去改變這一切，希望把自己認為好的方式給帶進來，於是接下來的工作就是重構程式碼了。 這也許大多數開發人員都經歷過，這種經歷是辛酸的（因為重構工作雖然重要，但是得不到過多的認可，目前國內關注的是可用性，對於程式碼質量並沒有得到應有的重視），也是甜蜜的（風雨之後總會有彩虹）。對於年輕的開發人員來說，見到彩虹的過程是痛苦、漫長地。他們都是在失敗中成長，這些失敗除了經驗外，主要是由於太急功盡力了，盲目的重構！ 盲目主要體現在： 1、在還沒有對系統整體架構有個清晰認識的時候，就想用自認為新的技術或架構來替換。 2、根本不分析現有系統架構或程式存在的弊端，只是一味地談設計模式，以設計模式中固有的一套來重構（在重構中，它只作為一個參考，而不是一個依據。） 3、重構比較隨性，每個版本的開發都跳出架構之外隨意帶入新的設計思想 這種盲目重構後給系統會帶來更多問題： 你會發現當你重構完後你的系統執行效率變低了， 系統中同時存在多種思想，新加入人員更難接手， 由於你沒有完全瞭解系統，反而在你的重構當中帶來了很多重複程式碼， 最悲劇的是你重構後的程式碼也被其他人當成垃圾，而進行重構。 那麼我們怎麼消除盲目呢！？ 首先，瞭解目前專案是否存在問題，存在什麼問題，這些問題是否能透過重構來解決，如果能，才進行重構，你的重構時間是需要公司給的，老闆不會因為你說依賴性強偶合性低就同意的，你必須要透過問題來讓他認識，關鍵的是隻有透過問題才能得到重構時間和資源，並且你的工作才能得到認可，這是一個很現實的情況。 接下來，你要確定重構的物件，是針對架構還是區域性程式碼，並且去設定一個理想的目標（為什麼是理想的？因為我們不可能一步到位，理想和現實是有差距的，但是我們要做的是盡力去往理想上靠攏）。 如果是針對架構進行重構，那麼這可不是一件輕鬆的事情，再真正開始之前需要做到以下幾點： 1、全面的瞭解系統的過去，包括以前的架構/技術背景、業務需求

業務程式碼不動，那重構的意義呢？重構之前，不是應該先梳理一下業務，確認哪些是可以最佳化，可以裁剪的，然後再重構

重構的目的是在不改變系統行為的前提下，對程式碼進行重新最佳化實現。單純的用業務程式碼限定重構的範圍不是特別明確。但是，重構一般要遵循漸進重構原則，切忌大規模的推倒性的全盤重構。

有點奇怪，你們確定專案重構這個目標的時候，沒有論證過的嗎？為什麼要重構、如何重構、如何保證工作交接，這些都要論證過具體措施之後，才決定重構的呀。都確定要重構了，還問如何保證業務程式碼不動，那證明確定重構的時候就沒考慮好這一方面，不會是拍腦袋決策的吧？專案要到重構這一步，肯定有它不得不如此的充分理由，既然如此，詳細考察怎麼做就是必須的。如果舊專案的程式碼可以讓你輕鬆保證不破壞業務，那麼它的設計的編寫已經基本到位，又何須重構！就是因為原系統一團糟，不能靠修修補補解決，才要重構。

計科專業從事軟體開發多年，專案中的程式碼重構也是經常性發生的事情，一旦專案要進行重構就意味著很多程式碼框架上做出調整優化了，所以業務程式碼很難保證一點不動，對於國內很多專案來講重構不是很多，畢竟大家都在忙著應用級的開發，很多企業應用級的開發由於開始階段在追求的進度對於質量要求不是很高，結果還在此基礎上不斷的堆積功能，最後效能很差被迫專案重構了，發生這種案例很多小型的網際網路公司經常發生的，一旦重構任何的程式碼都不可能一成不變了。

從技術的角度來講，優秀的產品都是千錘百煉出來的，這其中就包括有對模組的重構或者整體框架的重構的過程，對於一個軟體研發人員來講重構自己程式碼屬於一種職業習慣，很少有人能夠把程式碼直接一次性到位的，不自覺地重構程式碼也是優秀程式設計師必備的素質，經常在開源社群耍的人可以瞭解到開源社群程式碼變更非常迅速，程式碼的更新很大一部分其實不是新功能的增加主要是對於程式碼點點滴滴的最佳化，傳統的軟體行業基本上習慣於普通的員工的程式碼交給主管去稽核，稽核通過了就可以提交到程式碼倉庫裡面去了，國外很多優秀的軟體公司習慣於同事之間互相稽核程式碼，如果你的程式碼能夠成功說服你的同事就可以提交到程式碼倉庫中。

優秀的程式設計師認為程式碼質量就是自己的臉面，所以會不斷的提升自己程式碼的質量，所以不停的重構程式碼結構，一直修改到自己滿意為主，所以開源開源的社群更新的速度讓人髮指，而且一旦修改不成功會立即換成別的方案，對於模組的重構都是這個樣子更何況整體的框架的調整，程式設計師 的對於程式碼都有折騰的心思，就想盡一切的辦法讓自己寫的東西做到最最佳化。題目中涉及到的業務程式碼其實就是功能需求表，這種屬於具體的業務程式碼部分，這塊在專案中就是具備程式碼實現部分，框架調整一般是支撐各種模組的框架，但是在調整過程中業務程式碼一般儘量不去修改，但是調整過多難免會涉及到業務方面的程式碼。

對於初級的程式設計師來講可能對於程式碼的修改都包含著一種畏懼的心情，程式設計的程式碼都是專案中的工具而已，初學者可能就是對於工具如何使用需要一定時間的磨練。其實在專案重構的過程中是否要動到業務程式碼關鍵還是框架設計者如何進行設計了，一般來講重構的點最好不要涉及到具體的業務模組但是如果業務程式碼實在是差勁，難免涉及到需要重新寫了，這在軟體開發過程中也是非常常見的事情了。

重構專案，而保持業務程式碼不動，這的確是一個難題，但也不是做不到。我從事嵌入式軟體開發十多年，做過系統工程師和技術架構師，根據我的認知和經驗，來談一談這個話題吧。

通常情況是原有專案架構已經不滿足新增需求，可能是介面不豐富，也可能是底層平臺需要升級甚至是更換。但有想保持業務程式碼不動，最大的可能性就是業務程式碼的原作者已經不在專案所在團隊內，比如已經調離部門，甚至是已經離職。業務程式碼不是不能動，是不想動，甚至是害怕動，因為所做修改可能會引入新的Bug。如果這個專案的業務程式碼部分是外發的，那就更不希望動了，以減少風險和成本。

如果系統模組沒有拆分重組，新增或刪減。可以考慮的方案是，保持介面不變，包括返回值、引數、功能定義。如果系統模組有變更，那麼還要考慮增加一些空函式介面，主要是為了使得編譯透過。

如果底層平臺的變化很大，而又不想業務程式碼變動。前提條件的是原來的業務程式碼必須透過中間層來訪問底層，而不是直接訪問底層。這樣才有機會把變動部分透過原有API介面相容上。舉個例子，假如原來用的是I2C，現在要改成SPI。如果原來的介面都是直接的I2C操作，那麼就很難不動業務程式碼了，但如果原來的介面是以資料訪問的形式，那麼就可以在API內部替換成SPI方式。

如果原來真的直接訪問底層或者已被替換的模組，那怎麼辦？常用的方式是，對映。可以透過函式替換（Marco）或者函式指標（函式地址）的方式或者指令替換（指令重定義）進行重新對映。這樣做可以解決問題，但是對於閱讀體驗來講，業務程式碼就太好和系統層面擺在一起理解了。

重構專案，如果不能使得專案在將來數年內適用，那麼重構的意義其實不大，還不如重新架構，從0開始。很多開發團隊就是害怕從0開始，而總是在原有基礎上做大大小小的所謂的重構，其實大多數都是補丁級別。也許是為了節省成本，也許是害怕“神仙”祖傳程式碼。如果是這些情況，我建議採用新增模組、新增介面的方式，以滿足新的業務需求，保持原有系統和業務不動。

如果要重構專案，我建議在有必要的時候，大膽地修改業務程式碼。當然這個前提是，業務程式碼在團隊內可見。如果接受業務程式碼可以修改，那麼對於重構來講，會有更大的發揮空間。

更換平臺和方案，是專案重構的最佳時機，這個時候最適合做從0到1的工作。人員搭配方面，建議新舊平臺和方案的系統工程師、架構師（技術和業務）都參與重構工作，這樣才能最大限度的擴大重構的空間和發揮重構的意義。