重構隨筆——重構的原則

重構的基本原則之一：不改變軟件的可觀察行爲。

這一基本原則闡述的是咱們在作重構的時候，維持外部的功能外觀不變，讓用戶沒法感知重構的變化。其實這很好理解，重構與添加新功能二者的角色彷彿老是對立的。添加新的功能與重構所作的事情應該偏偏相反：不該該修改既有的代碼，只是添加功能而已。

咱們老是在不知不覺中切換二者的角色，業務需求老是要咱們添加新的功能，可是咱們在開發過程當中會發現，若是重構一下代碼，能夠更優雅的添加咱們的功能。因此你會發現二者其實並不是絕對對立：重構爲了更好的增新，增新則會帶來新的重構。

這與中國道家的陰陽理論不謀而合，「奇正相生，如循環之無故，孰能窮之。」沒有一勞永逸的重構，在代碼的編寫上，重構與增新老是循環往復，交織在一塊兒。分清你如今的角色就顯得很重要了，重構的時候必定要牢記本身的原則與初衷，這樣纔不會在重構上偏的太遠。

重構的時間原則：理論上，當你感受到代碼讓你寫起來以爲噁心的時候，意味着重構的時機已到。沒有什麼特定的時間去重構，想到了就去作，隨時隨地，不用爲重構留出特地準備的時間，你會發現你定好的時間老是或早或晚，早了沒有必要，晚了則承受了太多痛苦。可是在項目的開發中，咱們總要遵循必定的規範，那麼我建議是下面三個時機是最好的。

1.添加功能的時候。最重要的時機，你總會在新增功能的時候發現設計上不合理的時候，這是你能夠體會你設計上優缺點最敏感的時候，不要錯過這個時機。

2.修復BUG的時候。錯誤每每是因爲你的設計不合理而產生的，設計上的不合理會讓你產生對代碼的誤解，從而在修改代碼的時候引入新的錯誤。若是你的項目中老是有一些沒法一眼看到的BUG隱藏在角落裏，那麼這個時候你就須要考慮去重構你的代碼。

3.審覈代碼的時候。審覈代碼通常都是不少人在一塊兒或者是一個老手在審覈你的代碼，人們每每老是針對一個熟識的東西會無心識的過濾其優缺點。代碼也是，咱們須要別人給咱們提供建議，他們的建議是站在別人的角度，這對於咱們是尤其重要，代碼是要給人讀的，能寫出給機器讀的代碼很容易，寫出給人讀的代碼纔是高手。