자주 리펙토링을 하라.(2)

|



리펙토링을 하려면 소스 코드 속의 나쁜 냄새를 맡을 수 있어야 한다고 합니다.

"리펙토링"이란 책에서 켄트 벡(Kent Beck)과 마틴 파울러(Martin Fowler)가 이야기한 코드 속의 나쁜 냄새에 대해 정리해 보려고 합니다.

사용자 삽입 이미지


중복된 코드 (Duplicated Code)
- 동일한 소스가 여기 저기 사용된다면 반드시 리펙토링을 해야 한다고 합니다.
Extract Method (136), Extract Class (179), Pull Up Method (370), Form template Method (393)

긴 메소드 (Long Method)
- C 프로그래밍부터 시작해서인지 절차적 프로그래밍에 익숙한 경우, 하나의 메소드에서 모든 일을 처리하는 경우가 종종 있습니다. 긴 메소드는 쪼개야 한다고 하네요~
Extract Method (136), Replace Temp with Query (147), Replace method with Method Object (163), Decompose Conditional (276)

거대한 클래스 (Large Class)
- 클래스가 너무 많은 일을 하면 변수도 많아지고, 중복된 코드도 많아질 가능성이 높다고 합니다.
Extract Class (179), Extract Subclass (378), Extract Interface (389), Replace Data Value with Object (209)

긴 파라미터 리스트 (Long Parameter List)
- 메소드에 전달되는 파라미터가 길면 소스를 이해하는 것이 어렵기 때문에 수정하는 것이 낫다고 합니다.
Replace Parameter with Method (335), Introduce Parameter Object (339), Preserve Whole Object (331)

확산적 변경 (Divergent Change)
- 말이 좀 어려운데요..  A라는 클래스를 "가" 이유 때문에  3개의 메소드를 수정해야 하고, 또 "나" 이유 때문에 4개의 메소드를 수정해야 한다면.. 차라리 "A가", "A나"와 같이 두개의 객체로 만드는 것이 바람직하다는 것인데요.. 대략적으로는 알겠는데 정말 확 와닿지는 않네요..
Extract Class (179)

산타총 수술 (Shotgun Sugery)
- 역시 어려운 말입니다. -.- 자주 수정하는 부분인데.. 한번 수정할 때마다 여러개의 클래스를 수정해야 한다면 이를 하나의 클래스만 수정하도록 변경해야 한다는 겁니다. 요건 가끔 있을 것 같네요..
Move Method (170), Move Field (175), Inline Class (184)

기능에 대한 욕심 (Feature Envy)
- 메소드가 자신이 속한 클래스보다 다른 클래스를 더 많이 활용하고 있다면, 옮겨야 겠죠..
Move Method (170), Move Field (175), Extract Method (136)

데이터 덩어리 (Data Clump)
- 한 클래스와 관련없는 여려 데이터들이 모여있는 경우입니다. 각각의 역할에 맞는 여러개의 객체로 쪼개야 한다고 하네요..
Extract Class (179), Introduce Parameter Object (339), Preserve Whole Object (331)

기본 타입에 대한 강박관념 (Primitive Obsession)
- 기본 타입만을 고집하지 말고 Money 클래스, Range 클래스, 전화번호 클래스, 우편번호 클래스등 특정한 작업을 위한 작은 객체를 충분히 활용하라고 합니다.
Replace Data Value with Object (209), Extract Class (179), Introduce Parameter Object (339), Replace Array with Object (220), Replace Type Code with Class (255), Replace Type Code with Subclasses (261), Replace Type Code with State/Strategy (265)

Switch 문 (Switch Statements)
- Switch 문은 객체지향 코드에서는 다형성을 이용해 수정해 주어야 한다고 합니다. 기본적으로 Switch문이 중복성을 가지고 있기 때문이라고 하네요~
Replace Conditional with Polymorphism (293), Replace type with Subclasses (261), Replace Type Code with State/Strategy (265), Replace Parameter with Explicit Method (327), Introduce Null Object (298)

게으른 클래스 (Lazy Class)
- 클래스가 충분한 일을 하지 않을 경우, 제거해야 한다는 겁니다.
Inline Class (184), Collapse Hierarchy (392)

추측성 일반화 (Speculative Generality)
- 앞으로 필요할 것 같아서 미리 추가한 기능과 관련된 코드중 실제로 사용되지 않는 것은 삭제하라는 거네요
Collapse Hierarchy (392), Inline Class (184), Remove Parameter (318), Rename Method (313)

임시 필드 (Temporary Field)
- 객체 안의 인스턴스 변수가 특정 상황에서만 사용된다면, 이해하기 어렵게 되므로 변경해야 한다고 하네요.
Extract Class (179), Introduce Null Object (298)

메시지 체인 (Message Chains)
- 어떤 객체를 사용하기 위해 다른 객체에 물어보고, 다른 객체는 다시 또 다른 객체에 물어보고, 그 객체는 다시 다른 객체에 물어보고.. 이런 경우가 메시지 체인이라고 하네요~~
Hide Delegate (187)

미들 맨 (Middle Man)
- 클래스 메소드의 대부분이 다른 클래스로 위임하고 있다면.. 지나친 캡슐화를 사용한고 있다는 것인데요.. 리펙토링을 적용해야 한다고 하네요~
Remove Middle Man (191), Inline Method (144), Replace Delegation with Inheritance (404)

부적절한 친밀 (Inappropriate Intimacy)
- 지나치게 친밀한 클래스는 서로 갈라 놓아야 한다고 하네요..
Move Method (170), Move Field (175), Change Bidirectional Association to Unidirectional (236), Replace Inheritance with Delegation (401), Hide Delegate (187)

다른 인터페이스를 가진 대체 클래스 (Alternative Classes with Different Interface)
- 같은 작업을 하지만 다른 시그너처를 가진 메소드에 대해서 리펙토링 하라는 거네요..
Rename Method (313), Move Method (170)

불완전한 라이브러리 클래스 (Incomplete Library Class)
- 기존의 라이브러리 클래스가 가지고 있었으면 하는 메소드가 있다면 리펙토링을 통해 보완하라는 겁니다.
Introduce Foreign Method (194), Introduce Local Extension (196)

데이터 클래스 (Data Class)
- get / set 메소드만 가진 클래스.. 실제로 많이 만드는 데요~ 이런 경우 적절한 리펙토링을 하라는 거네요~
Move Method (170), Encapsulate Field (242), Encapsulate Collection (244)

거부된 유산 (Refused Bequest)
- 상속구조가 잘못된 경우, 새로운 형제 클래스를 만들고 리펙토링해야 한다는 이야기 입니다.
Replace Inheritance with Delegation (401)

주석 (Comments)
- 주석을 써야 할 것 같다면 먼저 코드를 리펙토링 하여 주석이 불필요하도록 하라는 거네요..
Extract Method (136), Introduce Assertion (306)

리펙토링은 최적화의 개념이 아니라.. 소스 코드를 이해하기 쉽게 만드는 겁니다.
소스 코드 속의 나쁜 냄새를 잘 파악할 수 있도록 위의 내용을 참고하시기 바랍니다.




Trackback 0 And Comment 1
prev | 1 | ··· | 3 | 4 | 5 | 6 | 7 | 8 | 9 | next