ologist`s blog2.0

꽤 오랫동안 이 책에 대해서 블로그에 글을 다수 올린거 같다.
뜻모를 이야기들도 올린 경우도 많았고, 좀더 보기 좋게 정리해서 올린 경우도 있었다.

Working Effectively with LEGACY CODE도 간단하게 정리를 해보자.



많은 이야기들이 나오지만 대부분 위의 것들을 지키기 위한 저자의 테크닉을 소개를 하는 책입니다. 개인적으로 이 책은 밀린 책들을 읽고나면 몇번 더 읽어야 할 책으로 선정이 되었다.

책에 나온 기술과 유사하지만, 나름대로 실무에 적용한 내용을 정리해서 차후에 블로그에 올리도록 하겠다.

과거에 struts의 action을 테스트를 하기 위해서 mock을 만들어 주는 오픈소스나 라이브러리를 다운받아서 스터디를 하고, 써본 경험이 다들 있을 것이라고 생각을 한다. Junit Recipe에서는 심지어 EJB까지 mock을 만들어서 테스트를 한다. 그 책을 보면, 테스트 못할 것이 정말 없다.

하지만, 이런 작업자체가 귀찮다고 느껴지지 않은가? 물론 mock을 아예 쓰지 말자는 얘기는 아니다. mock을 조금만 사용을 하고, 테스트를 용이하게 해보자는 것이다. 특히 서블릿 종속적인 API에서 벗어나 보자는 얘기를 하고 싶다.

왜, struts는 자신들이 아키텍쳐를 포기하면서, webwork기반의 struts2.0을 만들었을까? 사실상 struts는 이름만 남아있다고 해야 한다.

webwork의 장점 중의 하나가 Action마져도 POJO스타일을 유지 할수 있다는 것이다.

웹에 대한 정보나 서블릿에 대한 정보를 모두 interceptor를 활용을 해서 쿠키나 reuest에 대한 정보를 서블릿API에 종속적이지 않게 Action을 만들수 있는 것이다.

이 기법은 Adapt Parameter와 비슷하다. 하지만, 나같은 경우는 Fake인터페이스를 만들고 인터페이스를 변경하는 형태가 아니라, 쿠키값을 Map통해서 Action에 inject를 하고, action안에서 사용할 비즈니스로직이 도메인에 populate를 해주었다.

Action에서 setCookieMap(Map map)이라는 인터페이스가 생겼다. interceptor에서 key,value쌍으로 쿠키의 정보를 map에 넣어주는 형태인 것이다.

Cookie와 같은 서블릿 API는 Action에 존재를 하지 않고, interceptor에서만 서블릿API에 종속적인 코드가 들어가는 것이다. 물론, interceptor는 aspect적으로 필요한 로직들을 모듈화 시켜둔 것이고, 많은 action에서 재사용이 가능하다.

이것은 무엇을 의미를 하는가? Action을 new로 생성을 해서 파라미터 셋팅과 DI를 하면 바로 http에 대한 mock이 없이 테스트를 할수 있다는 것이다.


지난 주에는 Action테스트를 만들면서, Action존재하는 XXXContext를 다 제거했다.

ThreadLocal기반의 XXXXContext클래스를 좀 과용해서 서본적이 있었는데, 역시나 전역 객체(?) or 클래스는 코드의 가독성을 떨어뜨리고, 이해하기도 어렵다.

사용할 때는 웬지 편안하게 쓰는 듯 하지만, 사용한 곳에서 XXXContext를 제거하기 시작을 해봐라. 힘든 만큼 디자인이 좋지 않다는 것을 뜻하는 것이다.

뜬금없이 전역객체에 setter를 하고 다른 객체에서 비즈니스 로직을 처리하는 해괴한 행위를 안 할수 있게 된것이 가장 기쁘다.



P.326을 보면, 약간의 기법이 틀리기는 하지만, 목적은 비슷한 것을 볼수가 있다. dependency break작업은 더 가독성이 좋은 코드, 더 쉬운 유지보수, 테스트를 위해서 신경을 써줄수록 더욱 좋다.
    

클래스 이름이나 메소드 이름에 prefix나 suffix를 붙여서 명명을 많이 한다. suffix도 유행이 있는거 같다. 과거에는 주로 Manager와 util이 큰 유행을 하였느나, 최근에는 BO나 Support 등등이 유행을 하고 있다.

suffix를 모두 붙이는 가장 큰 이유중의 하나는 AOP를 위해서 명명규칙을 정해둔 것이다. 하지만, 세부적으로 정하지 않고, DAO나 VO를 제외한 모든 클래스를 BO로 두기에는 너무 두리뭉실하다. 인터셉터들을 만들때 반이상이 넘어가는 suffix라면 벌써 의미를 잊어 버린 것이다.

다음과 같은 글을 읽어보자.


최근에 코드를 보면 습관적으로 붙이는 BO라는 suffix를 보았을 때 이제는 좀 지겹다..^^

애매한 suffix들 Manager, Util, BO, etc이 도메인 모델(엔티티, VO)을 제외하고 모든 클래스에 붙어있지는 않은지?  다시 한번 자신의 코드를 확인해보고, 스페셜한 경우의 suffix가 아닌 의무적인 suffix가 되어 버렸을 때 그 네이밍에 대해서 경계를 하자. 진정한 의미를 이름에 담아보자

올해는 네이밍을 멋지게 만드는 법을 연습해야겠다.
고민하다가 클래스 이름 하나 만들었다. TasksAfterPosting

Facade만 suffix를 반드시 붙이고, 다른 클래스들은 의미에 맞게 sufffix들을 만들어 줘야 겠다.