字型: 小中
3、難以通過重構手法完成的設計改動
通過重構，可以排除所有設計錯誤嗎？是否存在某些核心設計決策，無法以重構手法修改？在這個領域裡，我們的統計資料尚不完整。當然某些情況下我們可以很有效地重構，這常常令我們倍感驚訝，但的確也有難以重構的地方。比如說在乙個專案中，我們很難（但還是有可能）將「無安全需求（no security requirements）情況下構造起來的系統」重構為「安全性良好的（good security）系統」。
這種情況下我的辦法就是「先想象重構的情況」。考慮候選設計方案時，我會問自己：將某個設計重構為另乙個設計的難度有多大？如果看上去很簡單，我就不必太擔心選擇是否得當，於是我就會選最簡單的設計，哪怕它不能覆蓋所有潛在需求也沒關係。但如果預先看不到簡單的重構辦法，我就會在設計上投入更多力氣。不過我發現，這種情況很少出現。
4、何時不該重構？
有時候你根本不應該重構 — 例如當你應該重新編寫所有**的時候。有時候既有**實在太混亂，重構它還不如從新寫乙個來得簡單。作出這種決定很困難，我承認我也沒有什麼好準則可以判斷何時應該放棄重構。
重寫（而非重構）的乙個清楚訊號就是：現有**根本不能正常運作。你可能只是試著做點測試，然後就發現**中滿是錯誤，根本無法穩定運作。記住，重構之前，**必須起碼能夠在大部分情況下正常運作。
乙個折衷辦法就是：將「大塊頭軟體」重構為「封裝良好的小型元件」。然後你就可以逐一對元件作出「重構或重建」的決定。這是乙個頗具希望的辦法，但我還沒有足夠資料，所以也無法寫出優秀的指導原則。對於乙個重要的古老系統，這肯定會是乙個很好的方向。
另外，如果專案已近最後期限，你也應該避免重構。在此時機，從重構過程贏得的生產力只有在最後期限過後才能體現出來，而那個時候已經時不我予。ward cunningham對此有乙個很好的看法。他把未完成的重構工作形容為「債務」。很多公司都需要借債來使自己更有效地運轉。但是借債就得付利息，過於複雜的**所造成的「維護和擴充套件的額外開銷」就是利息。你可以承受一定程度的利息，但如果利息太高你就會被壓垮。把債務管理好是很重要的，你應該隨時通過重構來償還一部分債務。
如果專案已經非常接近最後期限，你不應該再分心於重構，因為已經沒有時間了。不過多個專案經驗顯示：重構的確能夠提高生產力。如果最後你沒有足夠時間，通常就表示你其實早該進行重構。
**壞味道
1、重複的**。
如果你在乙個以上的地點看到相同的程式結構，那麼可以肯定：設法將他們合二為一。
2、過長的函式。
越短的函式會存活的時間更長，存活的更好。
3、過長的類。
如果想利用單一的類做很多的事情，那麼該類的內部會出現很多的instance變數，重複**就要接踵而至了。
4、過長的引數列。
太長的引數列難以理解，太多的引數會造成前後不一致，不易使用，一旦你需要更多的資料，就不得不修改它。
5、發散式變化。
一旦我修改軟體，我希望只在一處修改就好，如果不能做到這點，該壞味道就出現了。
6、煙霧彈式修改。
一旦軟體進行修改，你必須去對多個類的內部做小修改，該壞味道出現了。
7、依戀情結。
函式對某個類的興趣高過對自己所處之host類的興趣，壞味道出現了。
為什麼要重構
在現實工作中，重構 更多被用來成為彌補缺陷 增加功能 修改設計等工作，而很多人潛意識裡也認為重構就是修改 重寫 而這往往曲解了重構的本意。重構是乙個過程，是建立在不違背外在行為的前提下，對 進行修改，改進程式的內部結構。重構不等於重新設計，軟體工程裡一定要先進行設計，再進行編碼，而如果你在之後對設計...
為什麼要重構
什麼是重構 重構，用最簡單的一句話說 就是要在不改變系統功能的情況下，對系統的內部結構進行重新調整。重構的最直接目的在於改進軟體系統的內部架構。乙個好的結構可以更加適應於需求的變化，更好的滿足客戶的需求，最大限度的延長軟體系統的生命週期。為什麼要重構 在不改變系統功能的情況下，改變系統的實現方式。為...
為什麼你老被DDoS，這裡有N種科學解釋
過來人說，創業是知識的學習的無底洞，不僅要對業務了熟於心，還要做好深夜2點被同事 催醒說有幾十個g的流量正在衝擊你的伺服器 只詢問一件事 幾點啦?的準備。平均一次ddos攻擊可以耗費一家企業52000美元到444000美元的成本，主要取決於企業的規模。損失包括關鍵業務資訊丟失 無法實施企業運營 業務...