http://images.amazon.com/images/P/0201485672.01._PE_SCMZZZZZZZ_.jpg [[BR]] ISBN:0201485672 , [http://www.wowbook.com/generic/book/info/book_detail.asp?isbn=ISBN89-87939-60-X 리팩토링] || [[TableOfContents]] || http://www.refactoring.com/catalog/index.html - Refactoring 에 대해 계속 정리되고 있다. == Refactoring 이란 무엇인가? == * 프로그램의 내부구조조정. 실제로 해당 코드가 하는 역할은 수정하지 않으면서 내부구조를 더 효율적으로 수정하는 작업. (수학의 인수분해를 생각해볼 것) * 기존의 "디자인 후 코딩' 법칙과 반대된다. (TestFirstProgramming 에서 UnitTest - ["Refactoring"] 이 맞물려 돌아간다) * Refactoring 을 하기 위해서는 UnitTest code가 필수적이다. 일단 처음 Refactoring에 대한 간단한 원리를 이해하고 싶다면 UnitTest 코드 없이 해도 좋지만, UnitTest code를 작성함으로서 Refactoring 에 대한 효과를 높일 수 있다. (Refactoring 중 본래의 외부기능을 건드리는 실수를 막을 수 있다.) == Refactoring 을 함으로써 얻는 이득 == * 코드 디자인을 향상시킨다. * 코드를 깨끗하게 하여 이해하기 쉽게 해준다. * 버그 발생을 찾는데 도와준다. * 좋은 디자인으로서 프로그래밍 시간을 단축해준다. == Refactoring은 언제 하는가? == 특별히 때를 둘 필요는 없다. 틈나는 대로. Don Robert 의 The Rule of Three 원칙을 적용해도 좋을 것 같다. 1. 무엇인가 만들것이다. 그냥 만들어라. * 뭔가 비슷한 코드를 만들 것이고, 중복됨이 있은 경우에 당신은 주춤할 것이다. 하지만 어쨌든 일단 중복되는 내용이 있더라도 만들어라. * 다시 또 뭔가 비슷한 일을 한다. - Refactoring을 할 때이다. Refactoring 하라. Three Strike 법칙은 외우기 쉬워서 처음 Refactoring 을 하는 사람들에겐 적당하다. 하지만, 저 법칙은 주로 중복이 일어날 때의 경우이고, Rename Method/Field/Variable 같은 Refactoring 은 지속적으로 해주는 것이 좋다. 그리고 다음과 같은경우 Refactoring을 함으로써 이득을 얻을 수 있다. * 함수를 추가할 때 * 버그를 고칠 필요가 있을 때 * Code Review 를 하려고 할때 * Bad Smell 이 날때. - ["Refactoring/BadSmellsInCode"] == 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) 그리고 Refactoring 을 이해하는데 ExtremeProgramming 을 이해하면 도움이 될 것이다. == Refactoring 관련 토론 == ["RefactoringDiscussion"] == Refactoring 과 Test Code == ["Refactoring/BuildingTestCode"] == RefactoringCatalog == ["RefactoringCatalog"] === Chapter 13 Refactoring Reuse, and Reality === ["Refactoring/RefactoringReuse,andReality"] === Chapter 14 Refactoring Tools === ["Refactoring/RefactoringTools"] === Thread === ["Refactoring"] 과 TestDrivenDevelopment 는 일종의 메타패턴이다. (여기에 개인적으로 하나 더 추가하고 싶다면 ResponsibilityDrivenDesign) 두개에 충실하면 ["DesignPattern"] 으로 유도되어지는 경우가 꽤 많다. ["Refactoring"] 에 의외로 중요한 기술로 생각되는건 바로 Extract Method 와 Rename 과 관련된 Refactoring. 가장 간단하여 시시해보일지 모르겠지만, 그로서 얻어지는 효과는 대단하다. 다른 Refactoring 기술들의 경우도 일단 Extract Method 와 Rename 만 잘 지켜지면 그만큼 적용하기 쉬워진다고 생각. 개인적으로 Refactoring 을 적용하는중, 자주 이용되는 테크닉이 StructuredProgramming 기법인 StepwiseRefinement (Rename 도 일종의 StepwiseRefinement 기술이라 생각이 든다)라는점은 의외일련지 모르겠다. OOP 와 SP 는 상호배제의 관계가 아니기에. --["1002"] - VC용 Refactoring 도구는 없나요? C++ 이라는 언어에서 Refactoring 이라는 개념을 적용시키려면 TDD in VC++ 처럼 약간 복잡한 과정이 필요하겠지만요;; - [임인택] - 닷넷 다음 버젼에 추가된다고 어디서 본거 같은데.. -[인수] - Visual Studio 2005 Preview 버전 구해서 깔아봤는데.. 거기 없었던것 같았는뎅..;; 플러그인 형식으로 VS7 이나 7.1에서 [Refactoring] 할수 있게 해주는 툴은 구했음.. - [임인택] ---- See Also HowToStudyRefactoring, Xper:RefactoringWorkbook ---- ["Refactoring"]