和敏捷方法的教條主義者相比，我在軟件設(shè)計和實現(xiàn)之初，不會寄望于將來的重構(gòu)；而當(dāng)重構(gòu)真正需要發(fā)生的時候，我也會坦然面對。 按照Martin Fowler的定義，重構(gòu)是指在不改變行為的情況下改變代碼的內(nèi)部結(jié)構(gòu)。可是，在現(xiàn)實中，需要重構(gòu)的何止是代碼的內(nèi)部結(jié)構(gòu)，而往往是程序的整體結(jié)構(gòu)。這種現(xiàn)象是違背敏捷思想的。在敏捷開發(fā)者看來，如果持續(xù)進(jìn)行重構(gòu)，就會避免嚴(yán)重的缺陷。
盡管如此，但現(xiàn)實總是另一個樣子。 我曾經(jīng)遇到過大連小程序軟件開發(fā)的一個公司：因為歷史遺留的原因，這個系統(tǒng)開放了幾千個沒有進(jìn)行任何控制的API。這些API之間，業(yè)務(wù)上自相矛盾、實現(xiàn)上高度耦合，甚至有大量的冗余。更要命的是，這些API已經(jīng)被廣泛使用。在這種情況下，要保留代碼的外部行為是無法進(jìn)行重構(gòu)的。這樣的系統(tǒng)首先要在業(yè)務(wù)層面上進(jìn)行重構(gòu)。 影響重構(gòu)持續(xù)進(jìn)行的因素有很多，其中最大的未知因素在于人。盡管敏捷方法提出了很多好的實踐，但是由于大連小程序軟件開發(fā)人員技術(shù)能力上的差異以及團(tuán)隊中復(fù)雜的社會性，很多實踐都流于表面，比方說，在實施敏捷方法時，只是專注于形式化的例會、口號化的積極創(chuàng)新、保守的迭代目標(biāo)等。
所以，重構(gòu)的要求總是發(fā)生在問題爆發(fā)的時候，例如無法忍受的性能問題、漏洞百出的安全問題。在此之前，代碼重構(gòu)（表面上看不到成績，而主動性要求極高的活動）往往被忽視。忽視的結(jié)果就是產(chǎn)生“偽敏捷”，道理很簡單：沒有進(jìn)行代碼重構(gòu)，一切都是空談。 站在現(xiàn)實的角度上，無論你是否承認(rèn)大連小程序軟件開發(fā)公司的實力如何，重構(gòu)總是和系統(tǒng)級別的程序結(jié)構(gòu)聯(lián)系在一起。對于這樣的重構(gòu)，業(yè)務(wù)接口都無法保持不變（業(yè)務(wù)功能保持不變）。也許我們應(yīng)該把這種重構(gòu)稱為“再設(shè)計”。 好在我們還有一些選擇，例如，SOA、組件化。 SOA可以抽取現(xiàn)有系統(tǒng)中有價值的業(yè)務(wù)接口（如果有的話），可以開放出一組更加合理的新接口，從而實現(xiàn)對程序結(jié)構(gòu)的再組織。
組件化則是從系統(tǒng)內(nèi)部開始來重新組織系統(tǒng)的程序結(jié)構(gòu)。客戶管理軟件在開發(fā)過程中不可避免的一些問題，這的確是再設(shè)計的過程。我們會在以后的章節(jié)中討論這個話題。 從重構(gòu)的目的出發(fā)，我更傾向于組件化的方式。組件化可以讓程序結(jié)構(gòu)（實現(xiàn)同樣的業(yè)務(wù)功能）煥發(fā)青春，這種改變是由內(nèi)而外的，就像植入了一種好的基因。
