Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (19)
Destacado
Similar a Refactoring tutorial 1주차[refactoring 개요]
Similar a Refactoring tutorial 1주차[refactoring 개요] (20)
Refactoring tutorial 1주차[refactoring 개요]
- 1. 리팩토링 Tutorial 1주차 2011.11.4 심빈구
- 2. 목차 리팩토링 배경 리팩토링 정의 리팩토링 원리 왜, 언제?, 문제는? 냄새
- 3. 리팩토링 배경 : 리팩토링 이란? Bad Code Good Code 리팩토링
- 4. 리팩토링 배경: : Bad Code가 야기시키는 문제점 Broken Window Theory 나쁜코드에 의한 생산성 저하는 계속 악화됨
- 5. 리팩토링 정의 명사형 정의 “소프트웨어를 보다 쉽게 이해할 수 있고, 적은 비용으로 수정할 수 있도록 겉으로 보이는 동작의 변화 없이 내부 구조를 변 경하는 것” 동사형 정의 “일련의 리팩토링을 적용하여 겉으로 보이는 동작의 변화 없이 소프트웨어의 구조를 바꾼다.” 다음 방법으로 동작의 변경 여부 검증 테스팅 최대한 개발 Tool의 지원 기능 사용 아주 조심히 진행 Refactoring의 예 public int getCharge(int quantity) { public int getCharge(int quantity) { int charge = 0; int charge = 0; Date now = new Date(); Date now = new Date(); // 현재 Summer타임 기간이라면 if (isSummerTime(now)) { if (now.before(SUMMER_START)|| now.after(SUMMER_END)) { charge = quantity * WINTER_RATE + charge = quantity * WINTER_RATE + WINTER_SERVICEC_CHARGE; WINTER_SERVICEC_CHARGE; } else { } else { charge = quantity * SUMMER_RATE; charge = quantity * SUMMER_RATE; } } return charge; return charge } } private boolean isSummerTime(Date now) { return now.before(SUMMER_START) || now.after(SUMMER_END); }
- 6. 리팩토링 원리 : 왜 리팩토링을 해야 하는가? 프로그램을 빨리 작성하도록 도와줌 어떻게? 리팩토링은 디자인을 개선시켜 줌 디자인이 나쁜 코드는? 같은 작업을 위해 더 많은 코드 사용 중복이 많고 이해하기 어려움 수정 시 어려움으로 나타남 리팩토링은 소프트웨어를 더 이해하기 쉽게 만듬 리팩토링된 코드는 숨겨진 사용자인 유지보수자의 이해를 도움 낮선 코드에 대해 리팩토링 하면서 코드에 대해 이해하기도 함
- 7. 리팩토링 원리 : 언제 리팩토링을 해야 하는가? 틈틈이 계속 리팩토링 자체가 목적이 아니라, 다른 것을 하기 위해 리팩토링 을 하는 것이고, 리팩토링은 그 다른 것을 하는데 도움을 준다. 삼진 규칙 세 번째로 비슷한 것을 하게 되면 리팩토링을 한다 기능을 추가할 때, 버그를 수정할 때 코드에 대한 이해를 돕기 위해서 코드 검토 시 고수준의 의견을 얻을 수 있음 준비가 많이 필요함
- 8. 리팩토링 원리 : 두 개의 모자 기능 추가 리팩토링 기존 코드 수정 없이 새로운 기능 추가 기능 추가 없이 코드 구조 수정 테스트 추가 테스트 추가하지 않아야 함 테스트 정상 동작 확인 테스트 정상 동작 확인 개발할 때에는 모자를 자주 바꿔 쓰고(10분~30분), 한 시점에는 하나의 모자만 써야 한다.
- 9. 리팩토링 원리 : 리팩토링을 할 때의 문제 데이터 베이스와 연관된 코드의 리팩토링 인터페이스의 변경 Publish 된 인터페이스의 이름 및 파라미터에 대한 리팩토링 Ex) Android의 Service.onStart() 메소드 새로운 I/F를 만들고 Delegation 사용 예방책 : 애매한 메소드는 API에 넣지 말자 Publish 된 인터페이스의 Throw절의 변경 이 경우 Delegation 사용 불가 예방책 : Super Exception 사용 리팩토링이 어려운 디자인 변경 디자인에 실수가 있어 마음대로 리팩토링 할 수 없을 때 어떤 디자인 결정 사항이 너무 중요해서 리팩토링을 기대할 수 없는 경우 보안 문제, 퍼포먼스 문제 언제 리팩토링을 하지 말아야 하는가? 코드를 처음부터 작성 하는 게 나을 정도로 엉망인 경우 현재의 코드가 작동하지 않을 경우 마감일에 가까울 경우
- 10. 리팩토링 원리 : 사전 디자인과 리팩토링의 효용성 관계 “디자인으로는 생각을 아주 빨리 할 수 있지만, 그 생각에는 여 기저기 작은 구멍이 뚫려있다.” “With design I can think very fast, but my thinking is full of little holes” – Alistair Cockburn 리팩토링에 의해 사전 디자인의 Role이 변경됨 완벽한 사전 디자인이 아닌 적절한 솔루션을 제공하는 디자인이면 충분 리팩토링을 통해 변경에 많은 비용이 들지 않기 때문 따라서, 디자인이 단순화 됨 디자인 중심의 단점 설계 비용이 많이 든다. 복잡해 진다. 유지보수 비용이 상대적으로 많이 든다. 중복에 의한게 아닌 Complexity 때문
- 11. 리팩토링 원리 : 리팩토링과 퍼포먼스 리팩토링은 장기적으로 최적화 단계에 소프트웨어의 튜닝을 돕는다. 리팩토링을 통해 퍼포먼스 튜닝에 할당할 수 있는 시간을 얻을 수 있음. 프로그램이 잘 분해되어 있으면, 튜닝을 위한 분석 시 좀 더 세밀한 분석이 가능하다.
- 12. 냄새 냄새(코드냄새)는 코드에 잠재된 문제에 대한 경고 표 시 리팩토링을 해야 하는 문제점 표시 대표적 냄새 중복코드 부적절한 이름 기능에 대한 욕심 부적절한 친밀 주석 긴 메소드 긴 파라미터 리스트 Switch문
- 13. 냄새 : 중복 코드 가장 많이 발생하는 냄새 두 가지 중복이 있음 Obvious 중복 보통 Copy & Paste에 의해 발생 Unobvious 중복 계층구조의 병렬적 구현 비슷한 알고리즘(ex, 문자열, 도메인 특화 로직) 해결책 하나의 클래스에서 중복 ExtractMethod 두 형제 클래스에서 중복 ExtractMethod -> Pull Up Field or Pull Up Method -> Form Template Method
- 14. 냄새 : 부적절한 이름 잘못된 이름은 코드의 이해를 방해한다. “People often make assumptions based on the object names alone” – Word Cunningham 해결책 Rename Method Rename Field Rename Constants Tip ! 일관성 없는 상세이름 보다는 일관성 있는 광의의 이름이 적합 add, register, put, create -> add 일관성 있는 이름을 위해서 용어 사전은 필수적
- 15. 냄새 : 기능에 대한 욕심 특정 클래스 내의 메소드가 동 PriceCalculator Product 작을 위해 다른 클래스에 있는 .. calculate() .. getQuantity() 정보를 많이 필요로 하는 경우 bmethod() getDiscountRate() 해결책 Move Method
- 16. 냄새 : 부적절한 친밀 특정 클래스 내의 메소드가 다른 Class A Class B 클래스에 있는 메소드(private 이 .. .. 어야 할)를 더 많이 사용하는 경우 amethod() xmethod() bmethod() ymethod() 해결책 두 개의 독립적인 클래스가 엉켜 있다 면 Move Method 서로를 가리키고 있다면 Change Bidirectional Reference to Unidirectional 중재하는 클래스가 없기 때문에 엉켜 있다면 Extract Hierarchy-> Hide Delegate
- 17. 냄새 : 주석 주석은 대부분 코드가 명확 치 않다고 판단될 때 쓰임 주석은 나쁜 코드를 유도함 해결책 코드의 일정 블록 설명 Extract Method 메소드가 하는 일 설명 Rename Method 선 조건 설명 Introduce Assertion
- 18. 냄새 : 긴 메소드 긴 메소드는 코드를 이해하기 힘들게 만든다. 주석을 달아야 할 필요를 느낄 때 마다 메소드로 분리 해결책 Extract Method 주의점 코드의 이해를 돕기 위해서는 코드의 의도를 잘 나타내는 이름 지어야 부적절한 이름을 가진 짧은 메소드 집합은 긴 메소드보다 이해하 기 힘들다.
- 19. 냄새 : 긴 파라미터 리스트 객체지향 코드에서는 파라미터가 많을 필요 없다. 문제점 이해하기 어려움 일관성 없음 변경이 많이 됨 해결책 이미 알고 있는 다른 객체로부터 값 얻어올 수 있음 Replace Parameter with Method 매개변수가 하나의 Object로 부터 나오면 Preserve Whole Object 매개변수 데이터가 하나의 논리 객체로 부터 얻어지는게 아닐 경우 Introduce Parameter Object 주의점 Caller와 Callee간의 데이터 종속성을 만들고 싶지 않을 경우 리팩토링을 피해야함
- 20. 냄새 : Switch 문 Switch문은 본질적으로 중복의 문제를 발생 타입 추가 시, 관련된 모든 Switch문을 수정해야 함 좋은 OOP코드의 특징은 Switch문이 비교적 적음 해결책 동일한 조건에 대한 Switch문이 여러 곳에서 사용됨 Step 1: Extract Method를 통해 각 조건 절에서 코드 추출 Step 2: Move Method를 통해 연관된 코드를 옳바른 클래스로 옮김 Step 3: Replace Type Code with Subclass or Replace Type Code with State/Strategy 를 통해 상속구조 만듬 주의 Switch문의 중복이 많지 않다면 바꿀 필요 없음 20 Confidential 12/13/2011
- 21. 결론 리팩토링은 코드를 이해하기 쉽게 만든다. 리팩토링은 목표가 아니라, 다른 작업을 하기 위한 과 정이다. 리팩토링은 틈틈히 계속 해야 한다. 21 Confidential 12/13/2011