淺談重構

1.重構概念

在不改變軟件的外部行爲的基礎上，改變軟件內部的結構，使其更加易於閱讀、易於維護和易於變動。——《重構 改善既有代碼的設計》

說白了重構就是一系列的「等量變換」！

2.重構的風險

當咱們遇到公司前人留下的爛代碼時（不少時候咱們也是留下「爛代碼」的人），通常都是先開罵，其次就捉摸着乾脆重作算了，通常都不肯意修改和重構，咱們一般給出的理由是「代碼太爛了，還不如重作」，這也就騙騙產品狗和老大罷了，真實的緣由只有一個：裏邊埋坑太多，業務複雜，文檔缺失，改壞了要承擔後果。

因此重構有風險，重構需謹慎！

原則上若是你的老大不支持重構的話，你最好不要私自去作這件事，由於弄很差你改壞了就麻煩了，如今國內的互聯網公司成天把事故什麼的計入KPI，直接關係你的職業前程。

3.如何確保重構的成功

重構風險那麼大，是否是說咱們就不能作這件事了？若是我只是改了一個變量名，那應該不會有太大問題，仍是有點不放心，那就乾脆測試一下，事實證實本次重構百分百不會出什麼幺蛾子。這就給了咱們啓示：「小步快跑」 + 「及時測試」，由於這樣修改的代碼量少，所用時間也少，每次只關注一個方面，從而極大地下降了重構的風險。若是你能聽從這個原則，重構就是So Easy的事情！

4.重構方法

初步重構，咱們能夠：添加註釋、調整順序、重命名變量、進行分段，再進一步咱們能夠：抽取方法、抽取類、抽取接口等等，運用一些典型的設計模式，修改一些不合理的數據結構，優化算法，運用一些語言新特性改寫老的代碼，進行並行和異步編程等等 ，方法不一而論，但並非說都用上了就牛逼，可以在之後的實際工做中學着實踐應用其中一些典型的方法就已經難能難得了。

5.保證代碼質量

互聯網行業業務發展迅速，需求過多，程序員爲了趕工期每每「不擇手段」實現功能，亂七八槽可是卻實現了功能，心想之後有時間了再去重構，真實的調調是每每不了了之。再加上不少時候咱們對代碼又缺少有效的CodeReview，爛代碼就會愈來愈多，越到後面維護這些代碼越苦逼。與其之後高風險地重構，不如從一開始就注重代碼的質量，因此請一開始就以重構的思想寫代碼，作好CodeReview，從公司的層面來說若是能從長遠利益和維護成本角度來思考問題的話，就會明白代碼質量的重要性，高質量的代碼避免了大量的重構，下降了軟件的風險和公司的成本，無形中增長了公司的收益！