상세정보

1장. 리팩토링
비디오 가게에서 요금과 포인트를 계산하여 인쇄하는 프로그램을 예제로 하여 리팩토링이 무엇인지 감을 잡을 수 있도록 설명하고 있다. 디자인도 별로 좋지 않고, 객체지향적이지도 않은 코드가 Extract Method, Move Method, Replace Temp with Query 등의 리팩토링을 하나씩 적용해가면서 어떻게 좋은 디자인으로 바꾸는지를 보여준다.

2장. 리팩토링의 원리
리팩토링의 정의와 리팩토링을 해야 하는 이유, 언제 리팩토링을 해야 하고, 언제 하지 말아야 하는지 등에 대해 설명한다. 또한 후반부에서는 리팩토링에 있어서의 문제점, 리팩토링과 디자인의 관계, 리팩토링과 퍼포먼스 튜닝, 리팩토링의 기원에 대해 설명한다.

3장. 코드에서의 나쁜 냄새
리팩토링을 어떻게 하는지 아는 것과 리팩토링을 언제 해야 할지를 아는 것은 별개의 문제다. 이 장에서는 리팩토링이 필요한 코드를 악취가 나는 코드로 비유하고, 어떤 경우에 코드에서 악취가 나는지, 또 그 악취를 제거하기 위해서는 어떤 리팩토링을 써야 하는지를 설명한다.

4장. 테스트 만들기
리팩토링에서 테스트는 필수조건 이다. 이 장에서는 리팩토링에서 테스트의 중요성을 설명하고, 오픈소스 테스트 프레임워크인 JUnit을 이용하여 단위 테스트를 하는 절차를 설명한다.

5장. 리팩토링 카탈로그로…
5장부터 12장까지는 이 책의 핵심 부분인 리팩토링 카탈로그이다. 5장에서는 리팩토링 카탈로그가 어떤 식으로 구성되어 있는지 살펴본다. 또한 리팩토링을 할 때 변경된 클래스나 메쏘드, 필드를 참조하는 코드를 어떻게 효과적으로 찾아 수정할 수 있는지에 대해 설명하고, 리팩토링 기술이 얼마나 성숙되었는지에 대해 논의한다.

6장. 메쏘드 구성
지나치게 긴 메쏘드는 많은 문제를 유발한다. 메쏘드를 그 의미가 명확한 이름을 지어 잘게 분해하면 코드는 이해하기가 쉬워지고 재사용성이 더 높아진다.이 장에서는 긴 메쏘드를 여러 개의 작은 메쏘드로 만들기 위해 코드를 추출하는 리팩토링, 코드를 추출할 때 문제가 되는 임시변수를 다루는 리팩토링 등이 설명되어 있다.

7장. 객체간의 기능 이동
객체지향 디자인에서 가장 중요한 부분 중의 하나가 객체간의 역할 분담을 잘 하는 것이다. 이 장에서는 객체간의 역할 분담을 제대로 하기 위해 객체간 필드나 메쏘드를 이동하고, 클래스를 추출하는 리팩토링이 설명되어 있다.

8장. 데이터 구성
객체지향 언어의 장점 중의 하나가 전통적인 절차적 언어에서 사용할 수 있는 간단한 데이터 타입 이상의 새로운 타입을 만들 수 있는 것이다. 이 장에서는 객체의 특성을 잘 이용하여 데이터를 쉽게 다룰 수 있도록 하는 리팩토링에 대해 논의한다.

9장. 조건문의 단순화
복잡한 조건문은 프로그램을 이해하기 어렵게 한다. 이 장에서는 조건문을 단순화하여 코드를 이해하기 쉽게 바꾸는 리팩토링에 대해 다룬다. 특히 객체지향 프로그램에서는 다형성을 이용하면 조건문을 훨씬 간단하고 융통성 있게 다룰 수 있는데, 이와 관련된 리팩토링 또한 설명되어 있다.

10장. 메쏘드 호출의 단순화
이 장은 객체의 인터페이스를 보다 단순하게 만드는 리팩토링에 대해 탐구한다. 메쏘드를 직관적으로 보이게 하기 위해 메쏘드의 이름을 바꾸거나, 복잡한 파라미터를 다루는 방법 등과 관련된 리팩토링을 소개한다.

11장. 일반화 다루기
이 장에서는 일반화와 관련된 리팩토링을 다루는데, 이런 리팩토링은 주로 상속과 관계가 있다. 메쏘드를 클래스 상속 구조의 상위 또는 하위로 이동한다든가, 클래스 상속구조에서 수퍼클래스나 서브클래스를 추출하는 리팩토링을 살펴본다. 또한 상속을 위임으로 바꾸거나 반대로 위임을 상속으로 바꾸는 리팩토링에 대해서도 설명한다.

12장. 대규모 리팩토링
이 장에서는 대규모 리팩토링의 네 개의 예를 설명한다.

13장. 리팩토링 재사용, 그리고 현실
리팩토링이 가져다 주는 이점을 알지라도 리팩토링 하는 것에 대해서 마음 내켜하지 않는 개발자들이 있다. 이 장에서는 리팩토링을 받아들이는데 있어서 문제가 될 수 있는 위에서 말한 이슈에 대해 차례대로 다룬다.

14장. 리팩토링 도구
리팩토링 도구를 사용하면 리팩토링이 필요한 부분을 찾아주고, 리팩토링을 적용한 후에 동작이 달라진 것이 없는지 테스트하는 것과 같은 시간이 걸리는 작업을 대신 해 주기 때문에 리팩토링을 하는데 많은 도움이 되고 결과적으로 리팩토링 하는데 있어서 부담이 줄어들게 된다. 이 장에서는 리팩토링 도구를 가지고 실제로 리팩토링 프로세스에 어떻게 적용할 수 있는지 알아보고 리팩토링 도구에 필요한 기술적인 요구사항과 실제적인 요구사항에 대해서 알아본다.

15장. 모두 합치기
리팩토링하는 기술을 아는 것은 시작에 불과하다. 리팩토링 기술을 사용할 때와 사용하지 말아야 할 때, 리팩토링을 계속 진행할 때와 멈출 때와 같은 리팩토링을 하는 리듬을 알아야 한다. 그리고 리팩토링를 한 후에 동작이 리팩토링하기 전과 달라져서는 안 된다는 것을 명심해야 한다. 이 장에서는 위와 같은 내용를 기술하면서 또한 리팩토링을 하는데 도움이 되는 몇 가지 방법(원칙)을 제시한다.

정보제공 :

전통적인 소프트웨어 개발 단계는 분석-설계-구현-테스트로 이어진다. 개발 후반부의 변경사항을 최소화하기 위해서는 정확한 요구분석이 필요하고, 변경에 적절히 대처하기 위해서는 소프트웨어를 유연하게 설계하는 것이 중요하다.

그러나 모든 것을 미리 알 수는 없는 노릇이다. 아무리 정확하게 분석한다 하더라도 변경사항은 계속 발생하기 마련이다. 코드를 수정함에 따라 시스템의 본래 모습과 디자인된 구조는 점점 사라질 것이다. 또한 소프트웨어의 디자인을 유연하게 하는 것은 비용을 증가하게 하고, 코드를 이해하기 어렵게 한다.

리팩토링은 소프트웨어의 외부 기능을 변경하지 않으면서 내부 구조를 바꾸는 기술이다. 리팩토링을 사용하면 나쁜 디자인의 코드를 취해서, 외부 기능을 변경하지 않고, 좋은 디자인의 코드로 바꿀 수 있다. 따라서 리팩토링을 이용하면 처음부터 미리 모든 경우에 대해 고민하고, 필요할지 확실하지도 않은 유연성을 소프트웨어에 주기 위해 비용을 낭비할 필요가 없다.

처음에는 간단한 경우에 대해 코드를 작성하고, 나중에 문제가 복잡해지면 리팩토링을 하면 된다. 리팩토링의 각 단계는 아주 적은 작업만을 포함하고 있고, 또 각 단계마다 테스트를 하기 때문에 안전하게 소프트웨어의 내부 구조를 바꿀 수 있다.

리팩토링을 사용하면 작업의 밸런스가 바뀐다. 모든 것을 미리 생각하기보다는 개발을 하면서 지속적으로 좋은 디자인을 찾는다. 시스템을 구축하면서 어떻게 디자인을 개선할지에 대해 배운다. 그 작업은 개발이 계속되어도 프로그램의 디자인이 계속 좋은 상태로 남아있게 한다.

정보제공 :

목차

옮긴이의 글 = 5

추천사 = 7

서문 = 9

1장 리팩토링, 첫번째 예제 = 21

 시작 = 21

 리팩토링의 첫번째 단계 = 27

 statement 메소드의 분해 및 재분배 = 28

 조건문을 다형성(polymorphism)으로 바꾸기 = 54

 예제를 마치며 = 72

2장 리팩토링의 원리 = 73

 리팩토링의 정의 = 73

 왜 리팩토링을 해야 하는가 = 75

 언제 리팩토링을 해야 하는가? = 78

 관리자에게는 뭐라 말해야 하나? = 81

 리팩토링을 할 때의 문제 = 83

 리팩토링과 디자인 = 88

 리팩토링과 퍼포먼스 = 91

 리팩토링의 기원 = 93

3장 코드에서의 나쁜 냄새 = 97

 중복된 코드(Duplicated Code) = 98

 긴 메소드(Long Method) = 98

 거대한 클래스(Large Class) = 100

 긴 파라미터 리스트(Long Parameter List) = 101

 확산적 변경(Divergent Change) = 101

 산탄총 수술(Shotgun Surgery) = 102

 기능에 대한 욕심(Feature Envy) = 102

 데이터 덩어리(Data Clump) = 103

 기본 타입에 대한 강박관념(Primitive Obsession) = 104

 Switch 문(Switch Statements) = 104

 평행 상속 구조(Parallel Inheritance Hierarchies) = 105

 게으론 클래스(Lazy Class) = 105

 추측성 일반화(Speculative Generality) = 106

 임시 필드(Temporary Field) = 106

 메시지 체인(Message Chains) = 107

 미들 맨(Middle Man) = 107

 부적절한 친밀(Inappropriate Intimacy) = 108

 다른 인터페이스를 가진 대체 클래스(Alternative Classes with Different Interfaces) = 108

 불완전한 라이브러리 클래스(Incomplete Library Class) = 109

 데이터 클래스(Data Class) = 109

 거부된 유산(Refused Bequest) = 110

 주석(Comments) = 110

4장 테스트 만들기 = 113

 자체 테스트 코드의 가치 = 113

 JUnit 테스트 프레임워크 = 116

 테스트 추가하기 = 123

5장 리팩토링의 카탈로그로 = 129

 리팩토링의 형식 = 129

 참조 찾기 = 131

 리택토링은 얼마나 완벽한가? = 132

6장 메소드 정리 = 135

 Extract Method = 136

 Inline Method = 144

 Inline Temp = 146

 Replace Temp with Query = 147

 Introduce Explaining Variable = 151

 Split Temporary Variable = 155

 Remove Assignments to Parameters = 159

 Replace Method with Method Object = 163

 Substitute Algorithm = 167

7장 객체간의 기능 이동 = 169

 Move Method = 170

 Movie Field = 175

 Extract Class = 179

 Inline Class = 184

 Hide Delegate = 187

 Remove Middle Man = 191

 Introduce Foreign Method = 194

 Introduce Local Extension = 196

8장 데이터 구성 = 203

 Self Encapsulate Field = 205

 Replace Data Value with Object = 209

 Change Value to Reference = 213

 Change Reference to Value = 217

 Replace Array with Object = 220

 Duplicate Observed Data = 224

 Change Unidirectional Association to Bidirectional = 232

 Change Bidirectional Association to Unidirectional = 236

 Replace Magic Number with Symbolic Constant = 240

 Encapsulate Field = 242

 Encapsulate Collection = 244

 Replace Record with Data Class = 254

 Replace Type Code with Class = 255

 Replace Type Code with Subclass = 261

 Replace Type Code with State／Strategy = 265

 Replace Subclass with Fields = 270

9장 조건문의 단순화 = 275

 Decompose Conditional = 276

 Consolidate Conditional Expression = 278

 Consolidate Duplicate Conditional Fragments = 281

 Remove Control Flag = 283

 Replace Nested Conditional with Guard Clauses = 288

 Replace Conditional with Polymorphism = 293

 Introduce Null Object = 298

 Introduce Assertion = 306

10장 메소드 호출의 단순화 = 311

 Rename Method = 313

 Add Parameter = 316

 Remove Parameter = 318

 Separate Query from Modifier = 320

 Parameterize Method = 325

 Replace Parameter with Explicit Methods = 327

 Preserve Whole Object = 331

 Replace Parameter with Method = 335

 Introduce Parameter Object = 339

 Remove Setting Method = 344

 Hide Method = 348

 Replace Constructor with Factory Method = 350

 Encapsulate Downcast = 355

 Replace Error Code with Exception = 357

 Replace Exception with Test = 363

11장 일반화 다루기 = 367

 Pull Up Field = 368

 Pull Up Method = 370

 Pull Up Constructor Body = 373

 Push Down Method = 376

 Push Down Field = 377

 Extract Subclass = 378

 Extract Superclass = 384

 Extract Interface = 389

 Collapse Hierarchy = 392

 Form Template Method = 393

 Replace Inheritance with Delegation = 401

 Replace Delegation with Inheritance = 404

12장 대규모 리팩토링 = 407

 Tease Apart Inheritance = 410

 Convert Procedural Design to Objects = 416

 Separate Domain from Presentation = 418

 Extract Hierarchy = 423

13장 리팩토링, 재사용, 그리고 현실 = 429

 현실 검사 = 430

 왜 개발자들은 리팩토링을 꺼리는가? = 431

 현실 검사(재방문) = 445

 리팩토링에 대한 참고자료 = 446

 소프트웨어 재사용과 기술이전 = 446

 끝내는 말 = 448

 참고 문헌 = 448

14장 리팩토링 도구 = 451

 도구를 이용한 리팩토링 = 451

 리팩토링 도구에 대한 기술적 판단기준 = 453

 리팩토링 도구에 대한 실질적 판단기준 = 456

 마치며 = 457

15장 하나로 합치기 = 459

참고문헌 = 464

찾아보기 = 467