4. 악당2. 말도 안 되는 몰상식한 일정(추정)
월 화 수 목 금 금 금 월 화 수 목 금 금 금
월 화 수 목 금 금 금 월 화 수 목 금 금 금
월 화 수 목 금 금 금 월 화 수 목 금 금 금
월 화 수 목 금 금 금 월 화 수 목 금 금 금
월 화 수 목 금 금 금 월 화 수 목 금 금 금
월 화 수 목 금 금 금 월 화 수 목 금 금 금
월 화 수 목 금 금 금 월 화 수 목 금 금 금
월 화 수 목 금 금 금 월 화 수 목 금 금 금
월 화 수 목 금 금 금 월 화 수 목 금 금 금
14. Reengineering vs Refactoring정의
Reengineering
} Chikofsky and Cross, "The examination and alteration of a system
to reconstitute it in a new form".
} the modification of a software system that takes place after it has
been reverse engineered, generally to add new functionality, or to
correct errors.
Refactoring
} Martin Fowler, "disciplined technique for restructuring an existing
body of code, altering its internal structure without changing its
external behavior",
} undertaken in order to improve some of the nonfunctional
attributes of the software
} Tiny change in a computer program's source code that does NOT
modify its functional requirements.
16. 프로세스 차이
Reengineering
Legacy code To be
Restructuring Refactoring System Test
analysis architecture
Refactoring
Identify Find test Break Make changes
Write tests
change points points dependencies and refactor
17. 구조를 왜 바꾸려는 걸까요?
“코드가 자꾸 늙기 때문이죠”
스파게티 코드 다수 존재
Feature enhance, bug fixing으로
인한 코드 수정 어려움
미흡한 영향평가로 new bug 등장
코드 수정 비용 증가
18. 언제, 어떻게 Refactoring을 해야 하는가?
} 틈틈이 계속
} 리팩토링 자체가 목적이 아니라, 다른 것을 하기 위해 리팩토링을 하는 것이고, 리팩토링은 그
다른 것을 하는데 도움을 준다.
} 삼진 규칙
} 세 번째로 비슷한 것을 하게 되면 리팩토링을 한다
} 기능을 추가할 때, 버그를 수정할 때
} 코드에 대한 이해를 돕기 위해서
} 코드 검토 시
} 고수준의 의견을 얻을 수 있음
} 준비가 많이 필요함
} 언제 리팩토링을 하지 말아야 하는가?
} 코드를 처음부터 작성 하는 게 나을 정도로 엉망인 경우
} 현재의 코드가 작동하지 않을 경우
} 마감일에 가까울 경우
20. 구린내(Bad Smell)
} 구린내(Bad Smell)는 코드에 잠재된 문제에 대한 경
고 표시
} 대표적 냄새
} Duplicated code
} Long method
} Long parameter list
} Large class
21. Duplicated Code
} 가장 많이 발생하는 냄새
} 해결책
} 하나의 클래스에서 중복
} ExtractMethod
} 두 형제 클래스에서 중복
} ExtractMethod -> Pull Up Field or Pull Up Method -
> Form Template Method
27. Duplicated Code
Smell
} Code is similar but not the same
Refactor:
} Use Extract Method to separate the
similar bits from the different bits.
} Use Form Template Method.
28. Form template method
} 각각의 서브클래스에, 동일한 순서로 비슷한 단
계를 행하지만, 단계가 완전히 같지는 않은 두
메소드가 있다면, 그 단계를 동일한 시그너처를
가진 메소드로 만들어라
} 이렇게 하면 원래의 두 메소드는 서로 같아지므
로, 수퍼클래스로 올릴 수 있다.
30. Long method
} Object program having short methods live best and longest.
} Little methods are the most valuable.
} Longer methods are difficult to understand.
32. Long Parameter List
} Smell
} A method call requires passing long list of
parameters.
} Refactor
} Use Introduce Parameter Object.
33. Introduce Parameter Object
자연스럽게 몰려다니는 파라미터 그룹을 가지고 있다면
→ 그것들을 객체로 바꾸어라
} 같이 넘겨지는 경향이 있는 특별한 그룹의 파라미터에 대해
} -> 데이터 덩어리
} -> 객체형태로 묶일 수 있음
} 부가 효용
} 새로 생긴 객체에 들어가야 할 메소드가 쉽게 눈에 띔
} 이에 따라, 중복을 효과적으로 제거할 수 있음
34. Large Class
} Too many responsibilities
} Broken SRP
} SRP: Every class should have a single responsibility, and that
responsibility should be entirely encapsulated by the class. All its
services should be narrowly aligned with that responsibility.
35. SRP Test
단일책임원칙(Single Responsibility Principle)
SRP
•클래스가 한가지 책임만 가져야 한다는 원칙
•클래스나 모듈을 변경할 이유가 하나 뿐이어야 함
•큰 클래스 è 작은 클래스 여럿
작은 클래스와 협력해 시스템에 필요한 동작 수행
____________가 스스로 ___________ 한다.
각 줄의 첫 번째 공백에 모듈명을 적습니다. 두 번째 공백에 모듈의
메소드/함수 중 하나를 적습니다. 모듈의 모든 함수/메소드마다 이
를 수행합니다.
각 줄을 소리 내어 읽습니다. 읽은 내용을 이해할 수 있습니까? 실
제로 모듈의 함수/메소드가 의미하는 내용에 책임을 갖고 있어야
합니까?
36. SRP Test 예
Automobile
SRP 준수 SRP 위반
start(); ü
stop(); ü
changeTires(tires []); ü
drive(); ü
wash(); ü
checkOil(); ü
getOil(); ü
37. Extract Class
두 개의 클래스가 해야 할 일을 하나의 클래스가 하고 있는 경우
→ 새로운 클래스를 만들고 관련 있는 필드와 메소드를 새로운 클래스로 옮겨라
} 같이 변하거나, 서로 의존적인 데이터의 부분집합이 있다면,
} 해당 데이터의 부분집합을 별도의 클래스로 분리!
40. Tip1: 다시 프로세스로
Refactoring
Identify Find test Break Make changes
Write tests
change points points dependencies and refactor
Unit Test Case가 준비되어 있지 않다면 Refactoring을 해서는 안된다
41. Tip2: 매일 조금씩, self inspection과 병행하여 진행
The debt of design
42. Tip3: 좋은 도구 잘 활용하라
} Refactoring 지원 도구(IDE)
} Eclipse
} Visual Studio 계열
43. Tip4: 흔히 사용하는 refactoring 방법을 숙지하라
} Move Method
} Rename Class/Method
} Extract Method
} Extract Class
