패턴을 활용한 리팩터링 (조슈아 케리에브스키, 2011) 독후감

패턴과 리팩토링에는 자연스러운 관계가 있다. 패턴은 우리가 있고 싶은 곳이고, 리팩토링은 그곳에 이르는 방법이다.

리팩토링 p133

리팩토링 책에서 이런 중요한 말을 했지만 확실한 절친 인증은 못 했다. 이 책이 바로 둘 사이를 이어주는 안내서이다.

사전 설계에서 패턴을 사용하거나 또는 패턴을 너무 일찍 코드에 도입하는 대신, 특정 패턴이 꼭 필요한 시기에 리팩토링을 통해 도입하는 방법을 취했다. 패턴을 이용하는 이런 새로운 방법은 XP를 수용하면서 사용하기 시작했는데, 과도하거나 미진한 설계를 피하는 데 도움이 됐다. - p29

리팩토링을 통해 패턴을 도입한다. 이 책에서 주장하는 핵심. 여기는 이 패턴을 사용하면 좋겠군. 사전 설계에서 이처럼 생각해 패턴을 넣는다면 과도한 설계를 피할 수가 없다. <소프트웨어개발의 지혜 : 원칙 디자인패턴 실천방법>에서도 비슷한 얘기를 했다. 차근차근 코드를 발전시킨다. 그러다가 패턴과 연관성을 발견한다. 바로 그때 패턴으로 코드를 정규화한다.

패턴을 사용할 때, 더 복잡해지는 걸 저자는 항상 경계하고 있다. 그래서 패턴을 향하는 각종 리팩토링을 설명할 때, ’~하는 게 아니라면 괜히 설계만 복잡하게 만드는 것이다.’란 얘기가 빠지지 않고 나온다.

더 훌륭한 소프트웨어 설계자가 되려면, 훌륭한 소프트웨어의 설계가 어떻게 발전해왔는지 그 과정을 공부하는 것이 훌륭한 설계 자체를 공부하는 것보다 훨씬 중요하다. 그 발전 과정 속에 진짜 지혜가 숨어 있기 때문이다. - p38

리팩토링을 통해 패턴을 도입하는 과정에서 공부할 수 있다. 왜냐면 <Design Patterns>에 나온 패턴들도 수많은 리팩토링을 거치면서 발견한 것들이기 때문이다. 이런 과정을 중요시해서 자세하게 절차와 예제를 설명했다.

리팩토링은 그 결과로 패턴을 도입할 수도 있고 제거할 수도 있다. 또는 패턴으로 가는 중간 단계에서 머무르게 할 수도 있다. 그러나 진짜 목표는 패턴을 구현하는 것이 아니라 더 좋은 설계를 얻는 것임을 명심하기 바란다. - p66

패턴으로 정규화를 시키기 위한 리팩토링 패턴으로 가는 길에 그만두는 리팩토링도 소개한다. 난 도중에 그만두는 게 정말 인상적이었다.

패턴을 배우면 근질근질하다. 하지만 넣으면 모두가 불행해진다. 목표가 좋은 설계를 얻는 게 아니라 패턴을 구현하는 게 되기 때문이다. 그럼 그냥 배우기만 하고 써먹진 말아야 해? 아니다. 그럼 패턴은 언제 써야 하는가? 선배들의 경험과 지식이 녹아있는 패턴을 언제 써야 하는가? 바로 이에 대한 답을 주는 책이다. 패턴을 바로 쓰지 말고 선배들이 패턴을 발견하고 쓴 방법대로 패턴을 향하는 길에 리팩토링을 사용하라.

인상적인 문장

• 패턴은 프로그램 내에서 볼 수 있는 어떤 것이기도 하지만, 동시에 프로그램을 변환하는 것이기도 합니다. 각 패턴은 패턴 적용 전과 후의 모습으로 설명할 수 있습니다. 이는 패턴을 리팩터링으로 생각할 수 있는 또 다른 방법이기도 합니다. - Ralph Johnson - p15
• 이 책은 리팩터링과 패턴의 결합에 대한 것이다. 이 책에서는 설계 초기 단계부터 패턴을 적용하는 것보다 기존 설계를 개선하는 데 패턴을 사용하는 것이 더 낫다고 말한다. - p19
• ’리팩터링의 결과로 나온 구조’인 패턴에 많이 익숙해진 지금, 나는 패턴의 최종 결과나 그 결과의 구현이 의미하는 바를 이해하는 것보다 패턴을 목표로 한 또는 패턴을 지향한 리팩터링을 하는 이유를 이해하는 것이 훨씬 가치 있다고 생각한다. - p38
• 설계 부채는 다음 세 가지를 꾸준히 수행하지 않을 때 발생한다. 1. 중복 제거 2. 코드 단순화 3. 코드 의도 명료화 - p48
• 기술 문제를 논의하는 데 설계 부채라는 금전적 비유를 사용하는 것이 경영진을 설득하는 데 큰 도움이 된다는 것은 이미 검증된 사실이다. 설계 부채에 대해 말할 때 나는 반복적으로 신용카드를 꺼내 관리자에게 보여준다. - p48
• 패턴 중독은 패턴의 과용을 초래하는 경우가 많다. 패턴에 매혹되어 아무 코드에나 패턴을 사용해야 직성이 풀린다면, 패턴 중독이라 할 수 있다. 패턴에 중독된 프로그래머는 패턴 구현의 경험을 얻기 위해, 또는 정말 훌륭하고 복잡한 코드를 잘 작성한다는 명성을 얻기 위해 시스템에 패턴을 도입하려 노력할 것이다. - p59
• 패턴의 진정한 성과는 패턴을 현명하게 사용할 때 나타난다. 리팩토링은 중복을 제거하고, 코드를 단순화하고, 코드가 그 의도를 잘 드러내도록 하는 데에 우리의 주의를 집중하도록 함으로써, 패턴을 현명하게 사용하도록 도와준다. - p61
• 리팩토링을 통해 점진적으로 패턴을 도입하면, 패턴으로 인한 과도한 설계가 발생할 기회도 줄어든다. 그리고 리팩토링을 더 잘 이해할수록 패턴이 주는 즐거움을 이해할 확률도 높아진다. - p61
• 패턴의 구조 다이어그램은 명세가 아니라 단지 예제일 뿐이라는 것은 아무리 강조해도 지나치지 않을 것 같다. 구조 다이어그램은 우리가 가장 자주 본 구현을 나타낼 뿐이다. - Design Pattern 공동 저자 John Vlissides - p63
• 패턴 구현에 있어 최소주의자(minimalist)가 되는 것은 발전적 설계를 위한 연습의 일부다. 많은 경우, 패턴을 사용하지 않은 구현을 패턴을 사용하도록 발전시켜야 할 필요가 있다. 그렇다면 리팩터링을 통해, 패턴 구현의 단순한 버전을 우선 사용하도록 만들 수 있다. - p64
• 일반적으로 패턴 구현은 중복을 제거하고, 로직을 단순화하고, 의도를 잘 전달하고, 융통성을 높이는 데 도움이 돼야 한다. 그러나 위의 일화에서도 알 수 있듯이, 패턴에 얼마나 익숙하냐에 따라서 패턴에 기초한 리팩토링에 대한 인식이 달라질 수 있다. - p68
• JUnit을 개발한 Kent Beck과 Erich Gamma가 처음부터 가능한 많은 패턴을 적용하려 했던 것은 아니다. 단순히 프레임워크를 발전시키면서 설계에 패턴의 지혜를 재사용한 것이었다. … 그들은 패턴을 목표로 또는 패턴을 향해 리팩토링을 한 것이 분명했다. 그리고 패턴에 대한 지식이 그 리팩토링 작업에 가장 확실한 도움이 됐을 것이다. - p69
• 자신이 작성한 문장이라 할지라도 초연하고 비평적인 시각으로 반복해서 읽으면, 곳곳에서 잘못된 점을 계속 발견하게 될 것이다. - Barzun, Jacques - p75
• 조급하게 최적화를 시도한 코드는 그렇지 않은 코드보다 리팩토링하기 어렵다. 일반적으로, 코드가 최적화된 상태보다는 그 전의 상태에서 설계 개선을 위한 대안을 찾아내는 것이 더 쉽다. - p396
• 많은 사람들이 이 책을 읽고는 이런 패턴을 구현하는 절차를 외우려 할 것입니다. 또는 기존 프로그래밍 도구에 이런 대규모 리팩토링을 추가해야 한다고 떠들어댈지도 모르겠습니다. 두 접근법 모두 잘못된 것입니다. 이 책의 진정한 가치는 특정 패턴에 도달하기 위한 절차에 있는 것이 아니라, 각 절차에 이르는 사고 과정을 이해하는 데 있습니다. 리팩토링적인 사고방식을 배움으로써(수학적 사고 방식을 배웠던 것과 같이) 동작이 보존되는 절차를 통해 설계 문제를 해결하는 방법을 익히는 것입니다. - John Brant, Don Roberts (세계 최초의 리팩토링 브라우저 발명가) - p461

PS: #review 디자인은 죽었는가? – 마틴 파울러(Is Design Dead? – Martin Fowler) 참고

Update <2017-09-04 Mon> 표지 사진 교체