讀書心得#重構JavaScript 1. 什麼是重構？

什麼是重構？

重構是一系列的等量變換

系統重構，就是在的不改變軟體外部行為基礎上，改變軟體內部的結構，使其更易於閱讀、易於維護、易於擴充與易於變更。

持續不斷地對系統的內部品質進行改善與改進，就是重構的價值。

1.1 如何確保行為不被改變？

Ans: 單元測試、版本控制

單元測試

進行重構之前，務必先替程式碼撰寫單元測試。確保每個方法的「輸出結果符合預期結果」之後，才可進行重構。

接下來每重構一小步，就立刻執行一次單元測試，確認被重構的方法「行為沒有因為重構而被改變」。

只有測試通過了，這次重構才算成功！

版本控制

一般會採用小步快跑的方式進行重構，一次只重構一小部分，重構完馬上執行測試，測試通過後立刻上傳至版本控制（Git 或 SVN）。

這麼做的原因是，一但某個修改測試不通過，則還原回來。小步快跑可以讓重構的過程中，以最快速度發現修改的問題，將因重構錯誤帶來的損失減到最小！

畢竟人不可能避免犯錯:-P

---

1.2 為什麼我們不在意實作細節？

Ans：重構時只在乎受測程式的「輸出結果」與「預期結果」是否保持一致。

因此，對一個物件進行測試時，只需要測試其公開方法（Public Methods），並不需要測試受保護方法（Protected Methods）與私有方法（Private Methods）。正確的設計下，測試完所有公開方法後，所有的受保護方法與私有方法都會被執行完畢。若出現沒有被執行的方法，表示該方法該被遺棄，或移動至屬於這個方法的類別。

1.3 為什麼不在意不明確且未測試的行為？

Ans：還沒確定一段程式碼的行為是否符合預期之前，不可以對其進行重構！

遇到一段行為不明確的程式碼，可以對其撰寫單元測試，利用輸入的資料與輸出結果，來理解這段程式碼的用意與行為。

當這段程式碼有單元測試保護的情況下，才可對其進行重構。

1.4 為什麼不關注效能？

Ans：一般來說，不會在剛開始重構的階段就去在意效能，只在意程式碼是否有保持正確的輸出。

但是如果一個實作在太慢，我們就有必要先修改實作了！

如何對效能進行測試？透過 Benchmarking 套件，可以將執行函式的時間點當作「輸入」，並將運作完成的時間當作「輸出」。取時時間差回報效能的成功與否。

---

補充1：重構要小步快跑、避免大佈局

以往設計一個系統時，總是喜歡大佈局，全面整理系統需求、全面分析系統功能、全面設計系統、開發、測試。這樣的過程往往持續數個月。但是在完成成品之前，誰都不曉得會不會存在問題。這就是「大佈局」的詬病。

正因如此，系統重構時總是應該避免大佈局設計，盡量採用一個一個連續不斷的小設計，這就是所謂的「小步快跑」模式。

小步快跑展現了敏捷（Agile）軟體開發的特性，簡單與快速回饋，不要想得太多。

…當大佈局重構時，大腦開始思考各種複雜的問題，不用多久大腦就開始充血，然後神遊。最後的結果就是走向失敗。既然如此，為何不選擇「小步快跑」這種更快更簡單的方式呢？

補充2：重構的兩頂帽子

重構過程中，不可因為未來會可能會遇到現在處理不了的需求，就開始過度設計。

有限的預期是可以的，但不要想得過於遙遠！

預見性設計與過度設計往往只是一線之隔。

Ｑ：但若哪天真的變更需求，現在的設計不能滿足怎麼辦？

Ａ：可以先重構方法（Method），使其可以應付新需求，然後再添加新的程式碼，實現新需求，再更新單元測試（要能通過）。

「重構」與「利用重構來應付新需求」的過程，稱為「兩頂帽子」：

一頂是只重構而不新增功能，一頂是增加新的功能並實現新需求。

​