實踐中的重構

　　重構，早就不再是“奢侈品”，而是“日用品”?？v然如此，在自己的工作過程中，還是聽到很多關于重構的誤解。

　　首先，重構是日常工作。

　　許多人問過我這樣的問題，要不要拿出專門的時間做重構。作為一個程序員，重構就應該和寫代碼、寫測試一樣，是我們日常工作的一部分，只要你寫代碼，就應該重構。特別是當你在做TDD的時候，如果你只寫測試，編代碼通過，對不起，那根本不叫TDD，那叫測試先行。目前為止，我還沒有見過一個程序員，包括我自己在內，寫代碼是一遍就寫得非常整潔，無需重構的。通常都是第一遍寫出的代碼只能實現功能，然后，把它重構得符合整潔的要求。這里要說的重點是，別討論專門拿時間做重構，那就是你日常工作的一部分。

　　我知道為什么會有人問出這樣的問題，這就是接下來要說的：重構不是重寫。

　　對于很多人來說，他嘴上說的是重構，心里想的是重寫，所以，這事很大，不是一蹴而就的，所以，要專門劃撥時間來做。重寫，事確實不小。但也是有技巧可言的。我們這里所說的重寫，不是整個系統的重寫，那專門立項就好了，這里所說的是要調整項目的某個模塊，或是某個設計。

　　一旦設計到調整，實際上是對整個項目組編碼風格的一種影響，因為影響比較大，所以，可以考慮以技術債的形式在項目組內部提出來。如果項目組內達成共識，并且業務人員也同意給這件事留出時間，那就可以著手來做了。想要說服業務人員，最好是告訴他們，花多長時間做這件事，能給未來省下多少時間。即便所有人都同意這個調整的方案，真正在實施的時候，我們也需要按照重構的思路來做，這也是需要一些功夫的。

　　沒有測試的重構就是耍流氓。

　　對于ThoughtWorks內部的項目，測試多還是有保障的，但我周游天下時親眼見過一些沒有測試的巨大代碼庫，我能說的，趕緊花時間為你要寫的代碼補一些測試，然后再說重構的事。

　　具體到動手重構了，標準只有一個：重構可以隨時隨地停下來，不破壞任何測試。

　　這話說得很容易，但真要做到可絕非輕而易舉。我看到很多大動干戈的修改，中間無法停下，一旦發覺不對，只好推翻重來。我只能說，對于重構，這種做法只是理解了形，并不理解神。站著說話不要疼，事實上，我個人對重構的理解也是看到了有人用小步重構把一段代碼逐步改好之后，震驚之余，才理解原來重構應該這樣做。要知道，我也曾經是大刀闊斧之輩，那一刻，我皈依于小步重構。

　　小步重構，是需要刻意練習的。我是花了不少時間去練習，才能做出一些當初見到的重構效果。時至今日，我依然不敢說自己有十足的把握能夠小步重構每一段丑陋的代碼，內心中總有一種躁動，想一路劈殺過去，只能不斷與自己說，慢點，別急。

　　對于ThoughtWorker而言，內部總是有這樣機會見到小步重構，對于外部的人來說，經常參加ThoughtWorks的活動，應該也可以見到這種做法。

　　重構易，程序員人人知重構，重構難，做好重構者寥寥無幾。無它，刻意練習。

原文轉自：http://blogread.cn/it/article/6291