1. Refactoring 이란 무엇인가? ¶
- 프로그램의 내부구조조정. 실제로 해당 코드가 하는 역할은 수정하지 않으면서 내부구조를 더 효율적으로 수정하는 작업. (수학의 인수분해를 생각해볼 것)
- 기존의 "디자인 후 코딩' 법칙과 반대된다. (TestFirstProgramming 에서 UnitTest - Refactoring 이 맞물려 돌아간다)
- Refactoring 을 하기 위해서는 UnitTest code가 필수적이다. 일단 처음 Refactoring에 대한 간단한 원리를 이해하고 싶다면 UnitTest 코드 없이 해도 좋지만, UnitTest code를 작성함으로서 Refactoring 에 대한 효과를 높일 수 있다. (Refactoring 중 본래의 외부기능을 건드리는 실수를 막을 수 있다.)
2. Refactoring 을 함으로써 얻는 이득 ¶
- 코드 디자인을 향상시킨다.
- 코드를 깨끗하게 하여 이해하기 쉽게 해준다.
- 버그 발생을 찾는데 도와준다.
- 좋은 디자인으로서 프로그래밍 시간을 단축해준다.
3. Refactoring은 언제 하는가? ¶
특별히 때를 둘 필요는 없다. 틈나는 대로. Don Robert 의 The Rule of Three 원칙을 적용해도 좋을 것 같다.
- 무엇인가 만들것이다. 그냥 만들어라.
- 뭔가 비슷한 코드를 만들 것이고, 중복됨이 있은 경우에 당신은 주춤할 것이다. 하지만 어쨌든 일단 중복되는 내용이 있더라도 만들어라.
- 다시 또 뭔가 비슷한 일을 한다. - Refactoring을 할 때이다. Refactoring 하라.
그리고 다음과 같은경우 Refactoring을 함으로써 이득을 얻을 수 있다.
- 함수를 추가할 때
- 버그를 고칠 필요가 있을 때
- Code Review 를 하려고 할때
- Bad Smell 이 날때. - Refactoring/BadSmellsInCode
4. Refactoring 공부하기 ¶
Refactoring 책을 읽는 사람들을 위해. Preface 의 'Who Should Read This Book?' 을 보면 책을 읽는 방법이 소개 된다.
- Refactoring이 무엇인지 알고 싶다면 Chapter 1의 예제를 읽어나간다.
- 왜 Refactoring을 해야 하는지 알고 싶다면 Chapter 1,2를 읽어라.
- 어떤 부분을 Refactoring 해야 하는지 찾기 원한다면 Chapter 3를 읽어라.
- 실제로 Refactoring을 하기 원한다면 Chapter 1,2,3,4를 정독하고 RefactoringCatalog 를 대강 훑어본다. RefactoringCatalog는 일종의 reference로 참고하면 된다. Guest Chapter (저자 이외의 다른 사람들이 참여한 부분)도 읽어본다. (특히 Chapter 15)
7.3. Thread ¶
Refactoring 과 TestDrivenDevelopment 는 일종의 메타패턴이다. (여기에 개인적으로 하나 더 추가하고 싶다면 ResponsibilityDrivenDesign) 두개에 충실하면 DesignPattern 으로 유도되어지는 경우가 꽤 많다.
Refactoring 에 의외로 중요한 기술로 생각되는건 바로 Extract Method 와 Rename 과 관련된 Refactoring. 가장 간단하여 시시해보일지 모르겠지만, 그로서 얻어지는 효과는 대단하다. 다른 Refactoring 기술들의 경우도 일단 Extract Method 와 Rename 만 잘 지켜지면 그만큼 적용하기 쉬워진다고 생각.
개인적으로 Refactoring 을 적용하는중, 자주 이용되는 테크닉이 StructuredProgramming 기법인 StepwiseRefinement (Rename 도 일종의 StepwiseRefinement 기술이라 생각이 든다)라는점은 의외일련지 모르겠다. OOP 와 SP 는 상호배제의 관계가 아니기에. --1002
Refactoring
