# Working effectively with legacy code

## Chapter 1:
Primary reason to change software:
1. Adding a feature
2. Fixing a bug
3. Improving the design (refactor)
4. Optimizing resource usage (Optimizing)

## Chapter 2:
[Regression test](https://zh.wikipedia.org/wiki/%E5%9B%9E%E5%BD%92%E6%B5%8B%E8%AF%95)
Test hardness: testing tool

Unit test:
1. Run fast: 1/10th sec
2. Help us localize problem

SOP for modify legacy code:
1. 確定變動點在哪
2. 找出測試點
3. 解依賴
4. 編寫測試
5. 修改，重構

## Chapter 3:
建立假物件，來解依賴
有稍微提到mock object

## Chapter 4:
三個方式去借接，讓東西(你寫的class)可以測試
1. 聚集指令，來替代調code
2. compile之前把不想測的東西，指到別的地方，using .h file
3. extract method and override，就可以改掉原本的東西

## Chapter 5:
作者偷偷工商自己寫的套件= = CppUniteLite
稍微介紹一下測試工具:
1. xUnit
2. Junit
3. CppUniteLite
4. Nunit
#測試控制工具
1. FIT
1. Fitnesse

## Chapter 6:
* Sprout Method 新生方法
* Sprout Class 新生類別
* Wrap Method 外覆方法
* Wrap Class 外覆類別
* Decorator pattern 裝飾模式

| | 新生方法 | 新生類別 | 外覆方法 | 外覆類別 |
| ---- | ---------------------- | -------- | -------- | -------- |
| 優點 | 新舊程式被隔離開 | 1.增加信心度去修改 2.可測試 |獨立功能，低耦合| 介面隔離依賴 |
| 缺點 | 多了一些lagacy code |使系統複雜化 | bad naming | |

## Chapter 7:
Breaking dependency with interface
The dependency inversion principle
build time 增加，compile time減少，不會對原本class操作

## Chapter 8:
TDD
Programming by difference
liskov substitution principle

## Chapter 9:
解全域變數dependency
令人惱火的參數(參數化建構值)
-傳遞null 要小心
Null Object Pattern
隱藏依賴(解開建構值中的隱藏依賴)
-extract and override getter p368
-extract and override factory method p366
-supersede instance variable P421
構造塊 -前面幾個方法使用過程中，建構值過需要new更多物件
-推薦 工廠方法

有提到單例模式

## Chapter 10 I can't Get this class into a Test Hardness:
隱藏方法- 如果都要測試private，表示該類別做的事情太多了，要馬是public，要馬是放在新類別
有益的語言特性-不能修改的類別函氏的類別，借助依賴編輯器的概念p331，就可以透過介面來實作
無法探知的副作用-命令查詢原則，查詢需要有回傳值 不得改變物件，可以盡情使用，不怕被改變

## Chapter 11 I need to make a change. What methods should I test?:
用圖來顯示影響範圍

## Chapter 12 I need to make many changes in one area:
Interception point - a point in your program where you can detect the effects of a particular change
Pinch point - 所有修改匯集點
如果更改private method， 可以測call它的public method

## Chapter 13 I need to make a change but I dont know what test to write:
特徵測試 Method/Class
1. 為準備修改的程式碼區域編寫測試，直到你理解那段程式碼行為
2. 然後考慮你所要進行得修改，並針對修改編寫測試
3. 如果想要提取或轉換某些功能，那就編寫測試來驗證這些行為的存在性和一致性，一種情況一種情況編寫，別忘了附改轉移的程式碼

## Chapter 14 Dependencies on Libraries are killing me:
Dependencis on libraries can be avoided by using interface/ Wrap class 外覆類別

## Chapter 15 My application is all Api Calls:
Skin and Wrap the API
Responsibility-Based Extraction

## Chapter 16 I dont understand the code well enough to change it:
理解程式碼 UML refactor 可以畫草圖，清單標註 刪除不用的程式碼

## Chapter 17 My application has no structure:
架構師，用故事來讓大家對系統架構有一樣的概念，Naked CRC，反省你們的交流與討論

## Chapter 18 My test code is in the way:
測試命名原則，放的地方

## Chapter 19 My project is not object oriented. How do I make safe changes?:
解耦合技術，函數指標，改聚集，建構子，推廣物件導向

## Chapter 20 This class is too big and I dont want it to get any bigger:
單一職責
介面隔離
Ways to sort out responsibility
1. Group Methods
2. Look at hidden methods
3. Look for decisions that can change
4. Look for internal relationships
5. Lookf for the primary responsibility
6. When all else fails, do some scratch refactoring
7. Focus on current work

## Chapter 21 I'm changing the same code all over the place
Solve duplication by extract method and extract class
Open closed principle 開放封閉原則

## Chapter 22 I need to change a monster method and I can't write tests for it
Bulleted Methods
Snarled Methods
Manual Refactoring Challenge:
-Introduce Sensing Variable
-Extract What You Know
-Gleaning Dependencies
-Break out a method object
Strategy:
-Skeletonize Methods
-Find sequences
-Extract to the current class first
-Extract small pieces
-Be prepared to redo extractions

## Chapter 23
一次做一個目標，pair programing，幫助提升程式的品質，保持簽章，再重構時，不要改變原本呼叫方式。利用編譯器來找到要改的地方。

## Chapter 24
找到熱忱，團隊一起做一些事，可以更有動力。

## Chapter 25
建立interface 以及 假物件，來解依賴
分解出方法物件，抽出新的class，將常方法拉到新的class，所使用到的private method，放置新的interface
都大同小異，根據不同情境，去抽離不同level的依賴