難以通過重構(gòu)手法完成的設(shè)計改動
比如說在一個項目中，我們很難（但還是有可能）將“無安全需求情況下構(gòu)造起來的系統(tǒng)”重構(gòu)為“安全性良好的系統(tǒng)”。
這種情況下我的辦法就是“先想象重構(gòu)的情況”。考慮候選設(shè)計方案時，我會問自己：將某個設(shè)計重構(gòu)為另一個設(shè)計的難度有多大？ 如果看上去很簡單，我就不用擔心選擇是否得當，于是我就會選擇最簡單的設(shè)計，哪怕它不能覆蓋所有潛在需求也沒關(guān)系。但如果預(yù)先看不出簡單的重構(gòu)辦法，我就會在設(shè)計上投入更多力氣。
何時不該重構(gòu)？
重寫（而非重構(gòu)）的一個清楚的訊號就是：現(xiàn)有代碼根本不能正常工作。你可能只是試著做點測試，然后就發(fā)現(xiàn)代碼中滿是錯誤，根本無法穩(wěn)定運作。記住，重構(gòu)之前，代碼必須起碼能夠在大部分情況下正常運作。
另外，如果項目自己已近最后期限，你也應(yīng)該避免重構(gòu)。在此時機，從重構(gòu)過程中贏得的生產(chǎn)力只有在最后期限過后才能體現(xiàn)出來，而那個時候已經(jīng)時不我予。
Wrad Cunningharn的看法：未完成的重構(gòu)工作是“債務(wù)”。過于復(fù)雜的代碼所造成的維護和擴展的額外開銷，就是利息。你可以承受一定程度的利息，但如果利息太高你就會被壓垮。把債務(wù)管理好是很重要的，你應(yīng)該通過重構(gòu)來償還部分債務(wù)。
重構(gòu)與設(shè)計
Alistair Cockburn：有了設(shè)計，我可以思考更快，但是其中充滿小漏洞。
有一種觀點認為：重構(gòu)可以成為“預(yù)先設(shè)計”的替代品。這意思是你根本不必做任何設(shè)計，只管按照最初想法開始編碼，讓代碼有效運作，然后再將它重構(gòu)成型。極限編程的支持者極力提倡這種辦法。
但這不是最有效的途徑。極限編程的愛好者們也會進行預(yù)先設(shè)計。他們會使用CRC卡或類似的東西來檢驗各種不同的想法，然后才得到第一個可被接受的解決方案，然后才開始編碼，然后才能重構(gòu)。關(guān)鍵在于：重構(gòu)改變了“預(yù)先設(shè)計”的角色。如果沒有重構(gòu)，就必須保證“預(yù)先設(shè)計”的正確無誤，這個壓力太大了。

什么是CRC卡?
CRC(Class-Responsibility-Collaborator)卡建模是一種簡單且有效的面向?qū)ο蟮姆治黾夹g(shù)。在一個OO(面向?qū)ο?開發(fā)項目中，包括用戶、分析員和開發(fā)者在建模和設(shè)計過程中經(jīng)常應(yīng)用CRC卡建模，使整個開發(fā)團隊普遍的理解形成一致。
它由三部分組成：
1. 類(Class)
2. 職責(Responsibility)
3. 協(xié)作(Collaborator)
一個類代表許多類似的對象。而對象是系統(tǒng)模型化中關(guān)注的事物。他們可以是一個人、地方、事情、或任何對系統(tǒng)有重要性的概念。類名在CRC卡的頂部。
職責是類需要知道或做的任何事物。這些職責是類自身所知的知識，或類在執(zhí)行時所知的知識。
協(xié)作是指為獲取消息，或協(xié)助執(zhí)行活動的其他類。在特定情形下，與指定的類按一個設(shè)想共同完成一個(或許多)步驟。協(xié)作的類順著CRC卡的右邊排列。

(上圖出自http://book.csdn.net/bookfiles/116/1001163602.shtml)

在可以重構(gòu)的前提下，你只需要得到一個足夠合理的解決方案就夠了。
如果你在預(yù)先設(shè)計時在所有有可能出現(xiàn)變化的地方都建立起靈活性，卻在最后發(fā)現(xiàn)這些靈活性都毫無必要，這才是最大的失敗。你知道，這其中肯定有些靈活性的確派不上用場，但你卻無法預(yù)測到底哪些派不上用場。
而有了重構(gòu)，則只需要考慮：把一個簡單的解決方案重構(gòu)成這個靈活的解決方案有多大難度？如果答案是“相當容易”，那么你就只需實現(xiàn)目前的簡單方案就可以了。
重構(gòu)與性能
雖然重構(gòu)必然會使軟件運行更慢，但它也使軟件的性能優(yōu)化更易進行。除了對性能有嚴格要求的實時系統(tǒng)，其他任

 

何情況下“編寫快速軟件”的秘密就是：首先寫出可調(diào)軟件，然后調(diào)整它以求獲得足夠速度。
編寫快速軟件的方法：
1、時間預(yù)算法。
為每個組件分配資源（包括時間資源和執(zhí)行軌跡）；每個組件絕對不能超過自己的預(yù)算，就算擁有“可在不同組件之間調(diào)度預(yù)配時間”的機制也不行。例如心律調(diào)節(jié)器，在這樣的系統(tǒng)中，遲來的數(shù)據(jù)就是錯誤的數(shù)據(jù)。
2、持續(xù)關(guān)切法。
要求程序員在任何時間做任何事時，都要設(shè)法保持系統(tǒng)的高性能。
這種方式通常不會起太大作用。任何修改如果為了提高性能，通常會使程序難以維護，因而減緩開發(fā)速度。性能一旦被分散到程序各個角落，每次改善都只不過是從“對程序行為的一個狹隘視角”出發(fā)而已。
3、利用90%統(tǒng)計數(shù)據(jù)
90%的優(yōu)化都是白費勁，因為難得被執(zhí)行。
所以以一種“良好的分解方式”來建造自己的程序，不對性能投以任何關(guān)切，直至進入性能優(yōu)化階段。
優(yōu)化的過程：測量-->優(yōu)化-->編譯-->測試-->再次測量.
使用性能熱點測量工具“發(fā)現(xiàn)熱點、去除熱點”，直到獲得客戶滿意的性能。
McConnell提供了關(guān)于這項技術(shù)的更多信息。

 很想了解相關(guān)技術(shù),但是沒有找到具體資料.倒是有兩個開源項目

p-unit和junitperf
http://www.javapronews.com/javapronews-47-20030721ContinuousPerformanceTestingwithJUnitPerf.html