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

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

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

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

 

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

 很想了解相關技術,但是沒有找到具體資料.倒是有兩個開源項目

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