Blog

그림 출처: Yes24.com

필요한 배경 지식

이 책은 여러분이 상속, 다형성, 캡슐화, 컴포지션, 인터페이스, 추상/구체 클래스, 추상/static 메서드 등의 객체지향 개념뿐 아니라 단단한 혹은 느슨한 결합과 같은 설계 개념에도 익숙하다고 가정한다.

서문 – 필요한 배경 지식 (p.20)

만약 여러분이 객체지향을 배우기는 했지만, 여전히 이러한 개념을 생소하게 느낀다면 나는 다음과 같은 책을 추천한다. 각각 리팩토링과 디자인 패턴에 관한 책이다.

• Refactoring 리팩토링 : 나쁜 디자인의

  
  코드를 좋은 디자인으로 바꾸는 방법 – 마틴 파울러

• Head First Design Patterns : 스토리가 있는 학습법 – 에릭 프리먼

패턴을 활용한 리팩토링에서도 마틴 파울러의 Refactoring을 바로 옆에 두고 항상 참조할 것을 강력히 권고한다. 조슈아는 GoF의 디자인 패턴을 추천했다. 디자인 패턴을 정립한 기념비적인 작품인 것은 알지만, 내가 읽어본 적이 없다. 그래서 Head First Design Patterns를 추천한다.

패턴을 활용한 리팩터링의 예제는 Java로 작성되어 있다. 하지만 C#이나 Ruby와 같은 현대적인 객체지향언어를 다뤄본 사람이라면 누구나 쉽게 예제를이해할 수 있으리라 생각한다. 자바를 기준으로 봤을 때, 인터페이스, 추상 객체, 추상 메서드 정도만 알고 있으면 충분하다.

훌륭한 예제

역자의 말을 빌리자면, 불필요하게 패턴이 적용된 예제는 구하기 쉽다. 하지만 정말 리팩터링이 필요한 예제를 찾아서 제시하기란 쉬운 일이 아니다. 패턴을 활용한 리팩터링는 누구나 공감할 수 있는 실전적인 예제를 제시한다는 점만으로도 호평 받아 마땅하다. HTML Parser는 웹 관련 개발을 해 본 적이 있는 개발자라면 누구나 이해할 수 있을 것이다.

예제 자체만 훌륭한 것은 아니다. 저자는 예제 소스코드를 리팩토링하는 과정에 테스트 주도 개발을 접목시켰다. 이 책 한권으로 리팩터링, 디자인 패턴, 그리고 테스트 주도 개발을 모두 접할 수 있다.

TDD와 지속적인 리팩터링은 집중과 이완, 생산성을 극대화하는 간결하고 반복적이며 통제된 프로그래밍 스타일이다. Martin Fowler는 이를 ‘민첩한 느긋함 Rapid unhurriedness‘이라 표현했고 (TDD에서 Beck이 인용했듯이), Ward Cunningham은 이를 테스트에 관한 것이라기보다는 지속적인 분석과 설계에 관한 것이라 설명했다.

1장. 이 책을 쓴 이유 – 테스트 주도 개발과 지속적인 리팩터링

책 읽는 방법

패턴을 활용한 리팩터링은 크게 보아 두 부분으로 나눌 수 있다. 1장 – 이 책을 쓴 이유부터 5장 패턴을 고려한 리팩터링 카탈로그

까지는 리팩터링과 디자인 패턴 이론을 돌아보고, 더 나은 소프트웨어의 설계와 개발을 위해 이 두 기법을 어떻게 활용할 것인지 논의한다. 물론 논의의 결론은 짐작했듯이 이 책에서는 설계 초기 단계부터 패턴을 적용하는 것보다 기존 설계를 개선하는 데 패턴을 사용하는 것이 더 낫다는 것이다. 이 부분은 순서대로 차분히 읽어볼 것을 권한다. 저자의 소프트웨어 설계 철학을 엿봄으로써 나 자신의 문제를 파악하는 기회가 될 것이다.

6장부터 11장까지는 여러가지 리팩터링 절차를 설명한다. 생성, 단순화, 일반화, 보호, 축적, 그리고 유틸리티라는 분류에 따라 리팩터링을 구분해 놨다. 그러나 반드시 이러한 순서에 따라 책을 읽어야 하는 것은 아니다. 5장의 학습 순서에는 동일한 프로젝트를 예제로 사용하는 글을 기준으로 정리한 표가 제시되어 있다. 독자 자신에게 편리한 순서대로 읽으면 된다.

인상적인 구절

1. 많은 눈

   모자 가게의 간판을 제작하는 이야기가 나온다. 단순함의 미덕과 협업의 중요성을 일깨우는 흥미로운 이야기였다. 알아두면 두고두고 써먹을 이야기이다.

2. 설계 부채

   조직에 리팩터링을 공식적으로 도입하기가 쉬운 일은 아니다. 저자의 말마따나 ‘고장나지 않은 것은 고치지 않는다’는 관행 또는 무지 때문에, 많은 프로그래머들과 팀들이 설계 부채를 갚는 데 시간을 거의 투자하지 않는다. 경영진을 설득하기 위해 금전적인 비유를 사용하라는 것은 쉬우면서도 매우 실용적인 조언이었다.

3. Inline Singleton

   마지막 프로젝트를 돌이켜보건대 나는 싱글턴 중독자임이 분명하다. 이 객체는 하나만 있으면 충분해.라는 생각이 들면, 바로 싱글턴으로 리팩터링했었다. 그러다 보니 20개 정도, 어쩌면 더 많은 개수의 싱글턴 객체를 만들어냈었다. 앞으로는 조금 더 숙고한 후에 싱글턴을 도입해야겠다.

4. Replace Implicit Language with Interpreter

   class ProductFinder {
      public List byColor(Color colorOfProductToFind);
      public List byPrice(float priceLimit);
      public List bySize(int sizeToFind);
   
      // 하략...
   }
   

   나는 웹 프로그래머가 아니었지만, 일하다보면 ASP나 PHP 소스코드도 수정해야 할 경우가 있었다. 그때 보면 위의 소스코드와 같은 메서드를 수없이 볼 수 있었다. Replace Implicit Language with Interpreter 리팩터링 절차를 통해 이런 난잡한 코드를 깔끔하게 정리할 수 있다. 혹시 자신이나 주변 사람이 끝없이 나열되는 데이터베이스 관련 메서드를 방치하고 있다면, 이 리팩터링 절차를 습득하면 더 즐거운 하루가 될 것이다.

• Author Details

Author Details

최 재훈

Kubernetes, DevSecOps, AWS, 클라우드 보안, 클라우드 비용관리, SaaS 의 활용과 내재화 등 소프트웨어 개발 전반에 도움이 필요하다면 도움을 요청하세요. 지인이라면 가볍게 도와드리겠습니다. 전문적인 도움이 필요하다면 저의 현업에 방해가 되지 않는 선에서 협의가능합니다.

https://twitter.com/andromedarabbit

plaintext@andromedarabbit.net