ologist`s blog2.0

Refactoring to Patterns - 패턴을 활용한 리팩터링

자바개발자로서 생활을 하다가 보면, 신규 솔루션이나 새로운 도메인 영역을 개발을 해야 할때도 있지만, refactring역시 중요한 업무중의 하나이다.

국내 현실에 있는 대부분의 코드들은 OOP의 개념을 잡고 만든 코드들을 만나보기 힘들고, 양질의 코드보다는 단순 스크립트 코드들이 즐비한 상태이고, 중복 코드가 곳곳에 존재를 하며, 레이어간 분리가 잘 안된 경우도 허다하다.

이 코드들을 분석을 해서 refactoring을 하는 작업은 힘들고, 고통스러운 경우가 많다.
refactoring의 고통은 해본 사람들은 코드를 아예 재작성이 낫다고 얘기할 만큼 쉬운 것이 아니다.

refactoring을 하는 이유

• 새로운 코드를 더 쉽게 추가할 수 있도록 하기 위해
• 기존 코드의 설계를 개선하기 위해
• 기존 코드를 더 잘 이해하기 위해
• 덜 짜증나는 코드로 만들기 위해

refactoring을 하다가 보면, 더 자세히 코드를 보게 되고, refactoring을 통해서 나온 코드들은 자신이 읽기에 편하다. 그래서, 나는 기존 코드를 더 잘 이해하기 위해 refactoring을 선택을 자주 한다. 모르는 상태에서 버그를 일으키는 시스템보다는 좀더 공격적으로 코드개선을 통해서 risk를 관리해 나가는 것이 일정한 시점에 이르면 더 강건한 시스템을 만들 수 있기 때문이다.

리팩토링의 진정한 가치는 아래와 같은 그림, 링크에서 처럼 어느 순간에 급격하게 증가한다.
http://www.ologist.co.kr/376

막연했던 카탈로그들을 그 책을 본 동등한 필자(Joshua Kerievsky)가 그가 경험하고, 실전에 써먹었던 코드들을 바탕으로 책을 써내려간다. TDD 및 XP,애자일 사상이 곳곳에 보이는 이 책은 refactoring을 하고자 하는 이에게 나침반 같은 존재가 될것 이다.

refactoring의 방향성을 찾고 싶다면.
1. GOF 디자인 패턴
2. Refactorign - martin folwer
를 반드시 봐야 한다.

그리고, 이 책으로 좀더 실전적인 감을 익히고, 시작하면 더 양질의 코드를 만들수 있지 않을까 기대가 된다.

이 책의 목적

• 리팩토링과 패턴을 어떻게 결합하는지 이해
• 패턴을 고려한 리팩터링으로 기존 코드의 설계를 개선
• 코드에서 패턴을 고려한 리팩터링이 필요한 영역을 식별
• 새로운 설계의 초기부터 패턴을 사용하는 것보다 기존 코드를 개선하기 위해 패턴을 사용하는 것이 좋은 이유를 이해

Joshua Kerievsky
- XP전문기업 Industrial Logic(http://industriallogic.com)
- 전문 소프트웨어 개발자, 코치, 강사

패턴을 활용한 리팩터링

Joshua Kerievsky / Insight (인사이트)

ologist :
저는 최근들어서 패턴의 중요성을 더 느끼고 있습니다. 과거에는 패턴을 공부하고 프로젝트에 적용하려 애를 썼었습니다. 지금 거의 패턴을 잊어버렸다고 생각을 하고, 일단 프로젝트를 어느정도 구현을 하고, 중복코드를 없애는 작업을 했습니다. 그 다음 패턴책을 읽어보니 그 안에 중복코드를 없애려고 할때 생각했던 고민들이 있었습니다. 패턴을 위한 패턴이 아니라 중복코드를 줄이고, 유지보수 비용을 줄이기 위한 경험이라고 생각을 하면 반드시 필요하다고 얘기할수 있습니다

안영회님 :
넵.. 동감입니다. 그러나, 그러한 접근은 리팩토링에 가깝죠.
리팩토링을 하다 보면 패턴에 가까워진다는 설명이 자연스러울 수 있을 것 같습니다. 자주 코드를 개선하는 과정에서 결과를 만들어내는 것이 자연스러우니까요.
물론, 충분히 훈련된 분들에게는 바로 직관을 주는 패턴이 더 유용할 수 있겠죠.

서비스 클래스를 생성하는 방법(dependency)

• 다수의 팩토리 클래스
  XXXService xxx = XXXServiceFactory.getXXXService();
  YYYService yyy = YYYServiceFactory.getYYYService();
  ZZZService zzz = ZZZServiceFactory.getXXXService();
  xxx.doXXX();
  yyy.doYYY();
  zzz.doZZZ();
  
• ServiceLocator 클래스
  XXXService xxx = ServiceLocator.getXXXService();
  YYYService yyy = ServiceLocator.getYYYService();
  ZZZService zzz = ServiceLocator.getXXXService();
  xxx.doXXX();
  yyy.doYYY();
  zzz.doZZZ();
  
• Ioc 컨테이너
  interface , setter method, constructor

-        디자인 로직이 간단해진다

-        확장성이 좋아진다

-        Undo를 쉽게 구현할 수 있다.

-        Command 수행을 다른 thread 또는 다른 machine에서 수행할 수 있습니다.

-        EJB와 이를 사용하는 클라이언트를 분리합니다.

-        Deploy가 더 쉽게 만들어 줍니다. EJB인터페이스는 변경시키지 않고, command만 변경할수 있습니다.

-        한번의 서버 호출로 실행됩니다.(session facade역학 수행)

단점

-        객체를 사용하고, 폐기하는데 오버헤드가 있습니다.

-        EJB가 아니고, POJO이기 때문에 EJB컨테이너에서 제공하는 보안기능을 사용할 수가 없습니다.선언적 보안정의가 불가능합니다.

-        마찬가지로 command는 다양한 에러처리 로직을 갖지 못합니다. 따라서 에러처리 로직이 복잡해 집니다. 클라이언트에서는 직접 command객체의 에러를 발견해야 합니다.

-        대형 프로젝트의 경우 command 개수가 많아서 관리가 어렵습니다. 또는 request들이 한정적으로 정해진 경우에는 필요없습니다.

-        Command Receiver는 구조상 EJB들과 강하게 커플됩니다.