大話重構 第1章 重構：改變既有程式碼的一劑良藥

        第一章作者定義什麼是重構，說明重構的重要性。理論上最好有單元測試之後再進行重構，作者指出大師的書太過理想化，實際上工程師遇到的程式碼都沒有單元測試。

系統重構保證系統可以進行技術改造，又能有效避免改造過程的風險。

1.1  什麼是系統重構

對於系統重構的偏見：

系統重構是那些系統架構師、技術專家的高級技術，普通工程師不懂也沒有關係。

系統重構是大改程式碼，容易改出問題，還是不改比較好。

「多一事不如少一事」還是不要系統重構比較好。

 

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

測試是系統重構的保險索。

1.2  在保險索上走鋼絲

重構的測試標準只有一個，與之前的功能完全一致。

現實情況很難在重構之前建立自動化測試，初期還是先手工測試，一次只修改小部分程式。

QTP?

1.3  大佈局與小部快跑

大布局與小部快跑是兩種不同的軟體設計方式，大布局是制定好計畫依據計畫執行，然而預見性設計與過度設計往往只有一線之隔。小部快跑是活在當下，遇到問題解決問題。

1.4  修改軟體的四種動機

1.增加新功能

2.原有的功能含有BUG

3.改善原有程式的結構

4.改善原有系統的效能

要提升軟體品質，要做哪些事？ 首先要提高軟體的可讀性。

「領域驅動設計」將現實生活的人事物對應到程式。

抽取方法來分解難以閱讀與維護的大函數，用抽取物件來分解無所不能的大物件。

系統重構使軟體易於維護、易於變更。

1.5  一個真實的謊言

需求變更才是我們去重構的主要動因。

需要變更系統時，應將變更的過程分為兩個步驟，首先不添加任何功能，先重構我們的系統，然後開始變更實現新的需求。