import static으로 시작하는 static import는 주로 유틸리티성 메소드에 사용하는 스태틱 메소드나 스태틱 상수값 등을 사용할 때 적용하기 좋다. 지저분하게 클래스 이름이 주렁주렁 나오는 대신 깔끔하게 메소드 이름이나 값만 사용할 수 있으니 코드가 단순해지고 이해하기도 좋다. 물론 쓰기 편하다고 스태틱 메소드를 남용하면 안되겠지만.

자바 프로젝트에서 스태틱 메소드가 가장 활발하게 사용되는 곳은 테스트 코드다. JUnit 4.x 는 3.x까지와 다르게 수퍼 클래스를 상속하지 않고 테스트 클래스를 작성한다. 그래서 테스트 클래스가 별도의 상속구조를 가지거나 테스트 할 대상을 상속해서 테스트 클래스를 만드는 등의 기법을 적용하기 좋다. 반면에 상속을 하지 않으니 예전에 TestCase와 같은 수퍼클래스에 정의되어있던 assertEquals() 따위를 바로 사용할 수 없다. 어짜피 assertXXX 메소드는 독립적으로 실행되는 유틸리티성 메소드다. 스태틱 메소드로 만들어 적용하기 적절한 대상이다.

JUnit 4.x는 이런 메소드들을 org.junit.Assert 클래스에 스태틱 메소드로 정의해 두었다. JUnit 4.x에서 테스트 코드를 만들면 Assert.assertEquals() 처럼 스태틱 메소드를 써야 한다. 매번 Assert 클래스 이름이 나오는 것은 지저분하니 보통 static import를 사용하고 assertEquals()와 같은 식으로 간단히 코드에서 사용하게 된다.

Assert 메소드 뿐 아니다. 내가 애용하는 assertThat()의 경우는 hamcrest의 Matcher를 사용하는데 이때도 CoreMatchers 클래스의 is() 같은 스태틱 메소드를 사용하게 된다. Hamcrest Matcher를 확장한 JUnit이나 다른 오픈소스 Matcher를 이용한다면 해당 Matcher 스태틱 메소드도 import할 필요가 있다.

또 목 오브젝트를 사용한다면 EasyMock이나 Mockito 등에서 정의한 목 생성, 조작용 스태틱 메소드나 Mockito Matcher 스태틱 메소드도 사용해야 할 것이다.

이러다 보니 테스트 클래스를 만들 때마다 넣어줘야 할 static import가 제법 많다.

문제는 이클립스의 편리한 타입 검색, 자동 import 등의 기능이 스태틱 메소드에는 기본적으로 적용되자 않는다는 것이다. 프로젝트에서 사용하는 타입 정보야 미리 다 읽어들여서 몇 글자만 넣어도 빠르게 찾도록 만들어두었지만, 메소드 레벨까지 모두 지원하는 것은 너무 큰 부담이기 때문이다. 그래서 테스트 코드를 작성할 때 제법 많은 static import 문을 작성해야 하는데  상당히 번거롭다.

그래서 최신 이클립스에서는 static import를 보다 편하게 추가할 수 있도록 Favorites 라는 기능을 제공한다. 코드에서 자주 사용하는 스태틱 메소드나 스태틱 메소드를 가진 타입을 미리 Favorites에 등록해두면 해당 스태틱 메소드도 자동검색/완성 기능의 대상이 된다. 코드에서 assertThat이라고 입력하고 ctrl-space를 누르면 assertThat() 메소드를 바로 선택할 수 있고, 메소드를 사용하기 위해서 필요한 import 문도 자동으로 추가된다. 그래서 자주 쓰는 테스트용 스태틱 메소드를 등록해두고 사용하면 편리하다.

Favorites는 Preference의 Java – Editor – ContentAssist 아래 있다.

 

그런데 나는 Favorites을 사용하지 않는다. 한때 잠깐 쓰기는 했지만.

나는 코드를 작성할 때, 특히 테스트 코드를 작성할 때 리듬을 타면서 빠르게 코드를 완성해나가는 것을 즐긴다. 그런데 테스트 코드를 작성하다가 자꾸 static import를 위해서 타이핑을 멈추고 ctrl-space을 누르고 선택하는 것은 번거롭다. 한 두개래야지. 게다가 자동완성을 안하고 타이핑을 다 해버리면 끝장이다. 예를 들어 assertThat에서 멈추고 자동완성을 해서 import를 추가해줘야 하는데 그냥 빠르게 assertThat(xxx, is( yyyy )); 까지 치고 나면 당황스럽다. 그제서 키보드를 옮겨서 assertThat 뒤로 가서 ctrl-space를 누르고 assertThat() 메소드를 선택하면 import 만 깔끔하게 추가되야 할텐데, 바보 같은 이클립스는 메소드 템플릿을 다 추가해버린다. 그래서 코드가 assertThat(actual, matcher)xxx, is( yyy )); 처럼 볼쌍 사납게 변해버린다. (actual, matcher)를 지우고, 또 is 뒤에 가서 같은 짓을 반복해야 한다.

리듬은 끊기고 짜증만 난다. 그래서 테스트를 많이 작성하는 편인 나에게는 Favorites 기능이 그다지 매력적으로 느껴지지 않는다. 테스트 코드 작성을 위해서 Favorites 기능을 추천해주는 사람을 보면 과연 테스트 코드를 제대로 작성하고 있는 사람인지 의심부터 간다. –_-;;

 

그래서 Favorites는 조금 사용하다가 때려쳤다. 대신 static import를 위해서 Templates을 사용한다. Preference – Java – Editor 밑에 있는 Templates은 미리 간단한 이름를 정해놓고 이를 타이핑하고 ctrl-space를 누르면 미리 넣어둔 코드 조각(템플릿)이 한방에 나오는 기능이다. main은 main() 메소드를 만들 때 사용하고 sysout는 Sytem.out.println()을 만들어준다. 반복적으로 나오는 코드 패턴에 적용하기 좋다. 나는 여기에 ti라는 이름으로 다음과 같은 코드를 넣어놨다. ti는 test imports…

import static org.hamcrest.CoreMatchers.*;
import static org.junit.Assert.*;
import static org.junit.matchers.JUnitMatchers.*;
import static org.mockito.Matchers.*;
import static org.mockito.Mockito.*;

자주 쓰는 static import 문장을 * 와일드카드를 적용해서 통채로 넣어둔 것이다. 그리고 테스트 클래스를 만들면 제일 먼저 위에서 ti라고 치고 ctrl-space를 눌러서 이 import문을 넣는다. 그러면 끝. 이제 스태틱 메소드를 맘것 사용하면 된다. 테스트 코드를 복사할 때도 아무런 문제가 없다. 그냥 빠르게 타이핑 해도 된다. Favorites로 매번 번거롭게 하나씩 import 를 추가하는 것보다 100배 낫다.

대충 테스트 코드가 완성되면 ctrl-shift-O를 눌러서 organize imports를 한번 해주면 깔끔한 import 문으로 정렬된다. 언제든지 import 하지 않은 것이 있으면 한번만 ti 템플릿을 적용해주면 그만이다.

얼마전에 성철이 형이 물어봐서 답해줬던 내용이다.

많은 개발자들이 애플리케이션 서버로 톰캣을 사용하는 경우에 스태틱 파일(html, css, js, 이미지)은 톰캣 앞에 아파치 웹 서버(Httpd)를 두어서 처리하게 하는 것이 좋다고 생각한다. 외부의 요청은 일단 Apache Httpd가 받고, 톰캣 내에서 처리할 자바 애플리케이션만 톰캣으로 다시 전달해서 처리하고 그 외의 리소스는 Apache Httpd가 직접 처리하게 만들어야 성능이 좋다고 생각한다. 자바로 만든 서버인 톰캣은 스태틱 파일 처리에서 Apache Httpd만 못하다는 것이 그 이유다.

하지만 톰캣과 Httpd의 개발자에 따르면 이는 개발자들이 잘못 알고 있는 미신이다. 아직도 톰캣 3를 사용하고 있는 것이 아니라면 말이다.

자세한 내용은 Myth or truth: One should always use Apache httpd in front of Apache Tomcat to improve performance?에 잘 나와있다. 지금은 스프링 소스의 직원이 된 아파치 톰캣과 Httpd 의 핵심 개발자들이 직접 작성한 내용이다.

톰캣은 5.5부터 Httpd의 native 모듈을 사용해서 스태틱 파일을 처리하는 기능을 제공한다. 이 경우 Httpd와 톰캣이 같은 모듈을 사용하는 셈이니 성능에서 차이가 날 이유가 없다. 실제 테스트 한 결과를 봐도 톰캣에서 아파치 Native 모듈을 사용하는 것이 순수하게 아파치 Httpd만 사용하는 것과 비교해서 성능이 전혀 떨어지지 않는다.

따라서 단지 스태틱 파일 처리의 성능만을 위해서라면 굳이 톰캣 앞에 Apache Httpd를 두는 것은 불필요하다. 오히려 메모리만 많이 먹고, 관리부담은 커지고, 불필요한 부하만 걸릴 뿐이다.

물론 Httpd의 다른 기능이나 모듈을 사용해야 할 필요가 있다면 그때는 Httpd를 앞에 두고 사용해야겠지만. 예를 들어 하나의 서버에서 PHP 애플리케이션과 자바 애플리케이션을 함께 사용하거나, Httpd 서버를 간단한 로드밸런싱을 위해서 사용해야 하는 경우라면 Httpd를 앞에 두고 톰캣을 연결해서 사용하도록 하면 될 것이다.

마우스 제스처는 복잡한 단축키나 여러 번의 마우스 클릭이 필요한 반복적인 작업을 간단한 마우스 움직임 만으로 실행할 수 있게 해주는 기능이다. 상대적으로 마우스를 많이 사용하게 되는 브라우저에서는 필수 기능이다. 내가 가장 많이 사용하는 제스처는 탭 모두 닫기 기능이다. 탭 지원 브라우저를 사용하면 종종 필요 이상의 페이지를 여러 탭에 나눠서 띄우게 되고 그러다 보면 필요한 페이지만 놔두고 다 닫아버려야 할 때가 자주 있다. 그럴 때마다 x버튼을 눌러서 일일이 탭을 닫는 것은 불편한 일이다. Ctrl-W나 Ctrl-F4 같은 키를 누르는 것도 귀찮고, 탭으로 마우스를 끌어올려서 오른쪽 버튼을 누르고 close other tabs 메뉴를 선택하는 것도 번거롭게 느껴지기도 한다. 아마 제스처를 처음 사용하기 시작한 이유가 바로 이런 탭 한방에 닫기를 자주 사용해야 하기 때문이었던 것 같다. 마우스가 어느 위치에 있든 간단한 동작만으로 원하는 기능을 빠르게 실행할 수 있으니 이젠 없으면 불편해서 웹 서핑도 못할 것 같다.

그런데 이클립스를 사용하다보면 비슷한 상황이 종종 발생한다. F3나 Ctrl-클릭, F4, Ctrl-T, Ctrl-Alt-H 등으로 클래스, 인터페이스를 네비게이션 하면서 작업하다보면 소스 탭이 수십개로 늘어나는 것은 금방이다. 역시 그 때마다 탭에 마우스를 대고 Close others 메뉴를 클릭하는 것은 번거롭다. Close others 커맨드에 단축키를 할당하는 방법이 있긴하다. 하지만 대부분의 이클립스 단축키는 손가락이 꼬이는 키 세 개쯤은 결합해서 사용해야 하니 그다지 편하지도 않다.

그래서 이클립스에도 마우스 제스처 기능이 있으면 좋겠다 싶었다. 그래서 혹시나 하고 찾아보니 있다!

이름은 egest. 플러그인 홈피는 https://egest.dev.java.net/

설치를 하고 Mouse Gestures Config 뷰를 열어서 원하는 키와 커맨드를 바인딩 시킬 수 있다. 나는 기본 바인딩 항목에 Close others와 JUnit 테스트 실행 기능 두 가지를 추가해놨다. 마우스 움직임 한번으로 탭을 모두 닫거나 테스트를 실행할 수 있다. 완전 편해.

제스처 기능을 사용 하려면 먼저 툴바의 gesture switch 버튼을 눌러서 recognizer가 동작하게 해줘야 한다.

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha