作為軟件開發者的你，一定聽說過重構一詞，在我們平時的開發生活中，為了使代碼更加易于理解和處理一些代碼編寫過程中沒有注意到的問題，我們會相當頻繁的對我們的代碼進行重構處理。不過今天我在這里不是想講該如何重構，或者我們為什么要做重構，如果你的確有這方面的需求你可以查看《重構：改善既有代碼的設計》這本書。

今天我想講的是重寫，這是我作為一名入門級架構師屢試不爽的必殺技，在這里分享給你。

其實從思想和技法上來說，重寫應該可以歸類為重構，但有一點不同的，就是重構需要熟悉遺留代碼，而重寫不需要熟悉遺留代碼。

代碼是有生命力的，他會隨著時間的推移，逐漸的老去，失去活力。

寫出一段好的代碼，他的生命力將會很長（何謂好的代碼，其實有很多討論，例如應用SOLID原則編寫代碼，這個就不在這里討論了），但無論如何，他始終是有生命周期的，終將有老去和失去活力的一天，當那一天到來，我們應該決定推翻重做還是任由其自生自滅？

而且在團隊合作中，本來可能以你個人的素養，你可以做到代碼永世長青，但是你無法避免你的團隊成員破壞你代碼的生命力，當然有一個很好的實踐——只有代碼庫的Owner才能簽入代碼，任何由其他人完成的代碼都需要由Owner親自審核后，親自簽入，故他可以在簽入前，保證這段代碼的素質是符合自己的，但這對Owner的要求高，且若需要在短時間內開發大型工程就會有極大的局限，Github上的代碼幾乎都是用這種方式管理的，甚至像Linux這類源代碼也是用這種模式進行管理的。

若非上面那種實踐，設想你處于一個水平參差不齊的團隊，每個人負責一個模塊的開發，系統上線進入維護階段后，某人離職后發現其設計的模塊復雜且不易理解，有極大的難度讓后續人員去理解并進行修改，這個時候再來考慮重寫？

我知道你的疑問，一定會覺得這樣是不是成本更高，風險更加不易控制，若你是在這件事情已經發生后才開始考慮重寫這件事情，那不用想了，一定是成本很高，且風險極大，這種時候的確不建議輕易下結論重寫。

于是，我之所以寫這篇文章便是希望你能在發生這件事情之前就做好準備。

我們首先來分析一下，一般都會有些什么情況會導致重寫是必須發生的。

• 一個沒有經驗的開發者，他的一部分低素質代碼進入了代碼庫，導致后期難以維護
• 一個簡單的模塊通過多次打補丁的方式，變得異常復雜，以致后期難以維護
• 自己在早期由于對系統或者業務的理解不徹底，出現當時的設計無法充分滿足客戶需求的情況
• 一個復雜的模塊被發現有異常情況，其遺留代碼不易被理解，同時該模塊開發人員已無法找到
  

注解：所謂打補丁的方式，是指你在發現未被框架預先考慮到的異常情況出現后，通過判斷特定情況給予特殊處理的方式讓程序得以正常的方式。這種處理方式的潛在危害就是你不知道還會有多少個這種特殊情況存在。

我們是不是應該在這個時間到來之前，提前做一點什么準備呢？

• 充分定義好接口，將每個模塊的接口定義好，接口之間不應有強耦合，對于大部分情況均可參考典型的Rest風格設計，接口應盡量避免與特殊的應用場景配合，使得接口的調用必須遵循某種非直觀意識的調用規則。
• 縮小模塊范圍，使每個模塊的范圍減少，可以起到簡化接口及減少重寫工作量的作用。
• 對接口做好自動測試，TDD的好處在本文就不詳細闡述了，它是重構的重要根基，也同樣是重寫的重要根基。
• 使用新技術頻繁重構，注意這里是重構，這一條看起來好像和我們的標題偏了，但其實不然，畢竟重寫也是我們要盡量避免發生的事情，只不過是絕對沒有辦法完全避免的事情，故經常使用新技術重構系統，使得代碼更加精簡，有利于代碼生命力的延續，避免重寫這種高成本事件的發生。
  

末了，我還是得再強調一下，我的觀點不是要讓大家去經常重寫代碼，而是希望能夠讓大家認識到，一定會有不得不重寫代碼的可能性，尤其是在水平參差不齊的團隊中，所以提前為這種可能性做好準備，絕對比臨時抱佛腳強上很多倍。