More Related Content
Similar to 2017-refactoring-01-簡介
Similar to 2017-refactoring-01-簡介 (20)
More from Shang-Pin Ma (7)
2017-refactoring-01-簡介
- 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
- 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
Editor's Notes
- Clean Code?
- https://www.codepile.net/pile/b5rmLb0Z