資訊軟體人才培育推廣計畫教材

1. 資訊軟體人才培育推廣計畫
軟體重構簡介
馬尚彬 臺灣海洋大學資工系

2. ©2017 Software Engineering Consortium
參考書籍與教材
Martin Fowler, Refactoring-
improving the design of
existing code,1999
結城浩, Java 重構 (Java
Refactoring), 2008
劉建宏、陳偉凱、郭忠義，
Bad Smell Examples教材,
2010

3. ©2017 Software Engineering Consortium
• 何謂重構？
在不改變軟體程式外部行為的前提下，將軟體程式內部
的結構進行改善。
• 常用的手法是分解與重組。
• 以微小的步伐修改程式，如果犯下錯誤，很快就可以發現。
通常會在重構前進行單元測試(Unit Test)，重構後再進
行單元測試，以確保程式行為沒有改變。
何謂重構(Refactoring)
3
可想成Input與Output不改變

4. ©2017 Software Engineering Consortium
單元測試-範例
4
• 透過這個單元測試案例可以測試Money類別的add方法
• Add方法重構前與重構後均應執行此單元測試案例
• 單元測試課程請參考
https://sec.openedu.tw/courses/course-
v1:SEC+SE102.2+201609/about

5. ©2017 Software Engineering Consortium
• 改進軟體設計
• 使軟體更易被理解
• 讓Bug容易被發現
• 讓追加功能更簡單
程式碼容易超出所需、結構崩壞，變成Dirty Code。
重構可將結構崩潰且混亂的程式碼妥善地整理，變得較
有條理，如此一來，功能的追加就會變得輕鬆得多。
• 提高編程速度
重構的目的
5

6. ©2017 Software Engineering Consortium
• 重構不能替代設計
• 重構可以帶來更簡單的設計
• 重構可以減輕想一次到位的設計之壓力
重構與設計
6

7. ©2017 Software Engineering Consortium
• 程式中需要進行重構的部分，被稱為壞味道或
程式碼臭味(Bad Smell / Code Smell)。
• 當程式中有難以理解、難以修改、難以擴張這
些問題時，就可能存在壞味道。
代表該處隱藏著重建的可能性。
何謂壞味道(Bad Smell / Code Smell)?
7

8. ©2017 Software Engineering Consortium
重複了
在很多個地方散佈著相似的程式碼的狀態。
太長了
函式或類別如果太長，就會變得很難讓人理解。
名不符其實
函式或變數名字若無法表達其代表的功能，會讓程式不
容易瞭解。
壞味道的口訣1
8

9. ©2017 Software Engineering Consortium
公開太多了
變成public之後的函式可能被其他所呼叫，會有 [ 這個
函式若移除了，會不會有其他程式受影響? ] 的疑慮。
不太像是物件導向
大量使用switch敘述跟if敘述，充滿分歧的流程處理。
大量使用int，不建立專用的類別。
壞味道的口訣2
9

10. ©2017 Software Engineering Consortium
• 重構進行方式：
搜尋與確認程式碼中的壞味道。
搜尋重構目錄，找出此壞味道應透過何種重構方法解決。
• http://www.refactoring.com/catalog/
• http://www.industriallogic.com/wp-
content/uploads/2005/09/smellstorefactorings.pdf
根據重構方法進行程式碼之修改。
壞味道與重構
10

11. ©2017 Software Engineering Consortium
壞味道範例
11
-重複的程式碼 (Duplicated Code)
-過長的函式 (Long Method)
-過多的參數 (Long Parameter List)
-巨大的類別 (Large Class)
-魔術數字 (Magic Number)
-發散式改變(Divergent Change)
-散彈式修改(Shotgun Surgery)
-特性依戀(Feature Envy)
-重複資料群 (Data Clumps)
-過度使用基本型別 (Primitive Obsession)
- 缺乏註解 (Lack of Comments)

12. ©2017 Software Engineering Consortium
• 添加功能時一併重構
 讓添加新功能更快速與流暢
• 修補錯誤時一併重構
 讓程式碼清楚到可以發現bug
• 審查(review)程式碼時一併重構
 由開發者與審查者一起進行重構
 大型系統可根據設計模型進行重構
何時進行重構？
12

13. ©2017 Software Engineering Consortium
• 程式還不能執行的情況
 對於寫到一半還不能正常執行的程式，重構並無用
武之地。
• 時間緊迫的情況
 對於需急迫交件的程式碼而言，進行重構並非明智
之舉。
 重構的效果是隨著時間彰顯出來的。
何時不要進行重構？
13