Refactoring tutorial 1주차[refactoring 개요]

2,119 views

Published on

Refactoring tutorial 1주차[refactoring 개요]

Published in: Technology
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,119
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
0
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide

Refactoring tutorial 1주차[refactoring 개요]

  1. 1. 리팩토링 Tutorial 1주차 2011.11.4 심빈구
  2. 2. 목차 리팩토링 배경 리팩토링 정의 리팩토링 원리  왜, 언제?, 문제는? 냄새
  3. 3. 리팩토링 배경: 리팩토링 이란? Bad Code Good Code 리팩토링
  4. 4. 리팩토링 배경:: Bad Code가 야기시키는 문제점 Broken Window Theory 나쁜코드에 의한 생산성 저하는 계속 악화됨
  5. 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. 6. 리팩토링 원리: 왜 리팩토링을 해야 하는가? 프로그램을 빨리 작성하도록 도와줌 어떻게?  리팩토링은 디자인을 개선시켜 줌 디자인이 나쁜 코드는?  같은 작업을 위해 더 많은 코드 사용  중복이 많고 이해하기 어려움  수정 시 어려움으로 나타남 리팩토링은 소프트웨어를 더 이해하기 쉽게 만듬  리팩토링된 코드는 숨겨진 사용자인 유지보수자의 이해를 도움  낮선 코드에 대해 리팩토링 하면서 코드에 대해 이해하기도 함
  7. 7. 리팩토링 원리: 언제 리팩토링을 해야 하는가? 틈틈이 계속  리팩토링 자체가 목적이 아니라, 다른 것을 하기 위해 리팩토링 을 하는 것이고, 리팩토링은 그 다른 것을 하는데 도움을 준다. 삼진 규칙  세 번째로 비슷한 것을 하게 되면 리팩토링을 한다 기능을 추가할 때, 버그를 수정할 때  코드에 대한 이해를 돕기 위해서 코드 검토 시  고수준의 의견을 얻을 수 있음  준비가 많이 필요함
  8. 8. 리팩토링 원리 : 두 개의 모자 기능 추가 리팩토링 기존 코드 수정 없이 새로운 기능 추가  기능 추가 없이 코드 구조 수정 테스트 추가  테스트 추가하지 않아야 함 테스트 정상 동작 확인  테스트 정상 동작 확인 개발할 때에는 모자를 자주 바꿔 쓰고(10분~30분), 한 시점에는 하나의 모자만 써야 한다.
  9. 9. 리팩토링 원리: 리팩토링을 할 때의 문제 데이터 베이스와 연관된 코드의 리팩토링 인터페이스의 변경  Publish 된 인터페이스의 이름 및 파라미터에 대한 리팩토링  Ex) Android의 Service.onStart() 메소드  새로운 I/F를 만들고 Delegation 사용  예방책 : 애매한 메소드는 API에 넣지 말자  Publish 된 인터페이스의 Throw절의 변경  이 경우 Delegation 사용 불가  예방책 : Super Exception 사용 리팩토링이 어려운 디자인 변경  디자인에 실수가 있어 마음대로 리팩토링 할 수 없을 때  어떤 디자인 결정 사항이 너무 중요해서 리팩토링을 기대할 수 없는 경우  보안 문제, 퍼포먼스 문제 언제 리팩토링을 하지 말아야 하는가?  코드를 처음부터 작성 하는 게 나을 정도로 엉망인 경우  현재의 코드가 작동하지 않을 경우  마감일에 가까울 경우
  10. 10. 리팩토링 원리: 사전 디자인과 리팩토링의 효용성 관계 “디자인으로는 생각을 아주 빨리 할 수 있지만, 그 생각에는 여 기저기 작은 구멍이 뚫려있다.”  “With design I can think very fast, but my thinking is full of little holes” – Alistair Cockburn 리팩토링에 의해 사전 디자인의 Role이 변경됨  완벽한 사전 디자인이 아닌 적절한 솔루션을 제공하는 디자인이면 충분  리팩토링을 통해 변경에 많은 비용이 들지 않기 때문  따라서, 디자인이 단순화 됨 디자인 중심의 단점  설계 비용이 많이 든다.  복잡해 진다.  유지보수 비용이 상대적으로 많이 든다.  중복에 의한게 아닌 Complexity 때문
  11. 11. 리팩토링 원리: 리팩토링과 퍼포먼스 리팩토링은 장기적으로 최적화 단계에 소프트웨어의 튜닝을 돕는다.  리팩토링을 통해 퍼포먼스 튜닝에 할당할 수 있는 시간을 얻을 수 있음.  프로그램이 잘 분해되어 있으면, 튜닝을 위한 분석 시 좀 더 세밀한 분석이 가능하다.
  12. 12. 냄새 냄새(코드냄새)는 코드에 잠재된 문제에 대한 경고 표 시 리팩토링을 해야 하는 문제점 표시 대표적 냄새  중복코드  부적절한 이름  기능에 대한 욕심  부적절한 친밀  주석  긴 메소드  긴 파라미터 리스트  Switch문
  13. 13. 냄새: 중복 코드 가장 많이 발생하는 냄새 두 가지 중복이 있음  Obvious 중복  보통 Copy & Paste에 의해 발생  Unobvious 중복  계층구조의 병렬적 구현  비슷한 알고리즘(ex, 문자열, 도메인 특화 로직) 해결책  하나의 클래스에서 중복  ExtractMethod  두 형제 클래스에서 중복  ExtractMethod -> Pull Up Field or Pull Up Method -> Form Template Method
  14. 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. 15. 냄새: 기능에 대한 욕심 특정 클래스 내의 메소드가 동 PriceCalculator Product 작을 위해 다른 클래스에 있는 .. calculate() .. getQuantity() 정보를 많이 필요로 하는 경우 bmethod() getDiscountRate() 해결책  Move Method
  16. 16. 냄새: 부적절한 친밀 특정 클래스 내의 메소드가 다른 Class A Class B 클래스에 있는 메소드(private 이 .. .. 어야 할)를 더 많이 사용하는 경우 amethod() xmethod() bmethod() ymethod() 해결책  두 개의 독립적인 클래스가 엉켜 있다 면  Move Method  서로를 가리키고 있다면  Change Bidirectional Reference to Unidirectional  중재하는 클래스가 없기 때문에 엉켜 있다면  Extract Hierarchy-> Hide Delegate
  17. 17. 냄새: 주석 주석은 대부분 코드가 명확 치 않다고 판단될 때 쓰임 주석은 나쁜 코드를 유도함 해결책  코드의 일정 블록 설명  Extract Method  메소드가 하는 일 설명  Rename Method  선 조건 설명  Introduce Assertion
  18. 18. 냄새: 긴 메소드 긴 메소드는 코드를 이해하기 힘들게 만든다. 주석을 달아야 할 필요를 느낄 때 마다 메소드로 분리 해결책  Extract Method 주의점  코드의 이해를 돕기 위해서는 코드의 의도를 잘 나타내는 이름 지어야  부적절한 이름을 가진 짧은 메소드 집합은 긴 메소드보다 이해하 기 힘들다.
  19. 19. 냄새: 긴 파라미터 리스트 객체지향 코드에서는 파라미터가 많을 필요 없다. 문제점  이해하기 어려움  일관성 없음  변경이 많이 됨 해결책  이미 알고 있는 다른 객체로부터 값 얻어올 수 있음  Replace Parameter with Method  매개변수가 하나의 Object로 부터 나오면  Preserve Whole Object  매개변수 데이터가 하나의 논리 객체로 부터 얻어지는게 아닐 경우  Introduce Parameter Object 주의점  Caller와 Callee간의 데이터 종속성을 만들고 싶지 않을 경우 리팩토링을 피해야함
  20. 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. 결론 리팩토링은 코드를 이해하기 쉽게 만든다. 리팩토링은 목표가 아니라, 다른 작업을 하기 위한 과 정이다. 리팩토링은 틈틈히 계속 해야 한다. 21 Confidential 12/13/2011

×