어떤 개발자의 데스크탑 화면

인터넷에서 어떤 개발자의 데스크탑 화면을 보게 되었다. 이 사진은 2004년 8월의 것. 주소를 얘기하자면 이쪽 이다.

이 화면이 재미있어서 한참을 살펴보았다.
2004년 정도에 옆으로 기다란 화면을 하고 있는, early adopter인듯 해 보이는 것은 둘째치고,
gvim으로 java 프로그래밍을 하고 있는 것도 차치하고(그런데 IntelliSense기능없이 이렇게 프로그램을 하는게 가능?) 가장 시간을 들여서 보았던 것은 바로

왼쪽의 GVIM의 소스의 내용!

보면 runnablequery라고 하는 패키지의 어떤 xxxProcessor라고 하는 클래스를 작성하고 있는데, 이 클래스 안에서 public static void main을 정의하고 있다. 아마도 작성하고 있는 클래스를 테스트 하기 위한 코드인 것 같은데,

2004년에 JUnit이 존재하지 않거나 많이 사용되지 않았나?
또는 테스트 프레임웍을 쓰기가 귀찮았나?(실제로 지금의 프로젝트도 20001년부터 작성되어온 시스템이어서 테스트프레임웍을 사용하고 있지 않았는데, 내가 JUnit을 사용한 코드를 commit하기라도 하면(실수로 commit했었다), 다른 개발자들의 환경에 JUnit이 없어 compiling이 broke됐다고 complained되었었다.)

저런 방법은 간혹 사용했던 적이 있지만, 그렇게 멋있어 보이지 않았기 때문에 소스안에서도 제일 마지막에 넣거나 했는데, 지금 저렇게 사용한 화면을 보니, 이 클래스를 어떻게 사용해야 하는지 가장 명시적으로 알려주는 help가 되는 것 같다.
사실 최근에는 Test Framework도 하나가 아니라 여러 종류여서 TestSuite만드는 것도 꺼려지는데, 저 복고풍의 TestCase가 다시 Simple하고 멋있어 보여진다.
deploy할 때 테스트하는 코드가 포함되어져 binary의 크기가 커져버리는 문제만 제외하면(그것도 static function이기 때문에!) 이쪽이 훨씬 우수한 것 같다. 컴파일 할 때 특정 함수만 제외하는 방법이 있을까? Ant로 어쩌면 가능할까? 하긴, GVim이 SDI이기 때문에 여러 파일을 open하는 것이 꺼려지기도 했겠지.

제일 첫 라인을 보면, comment되어 있는 것은 파일이 제대로 있었는지 확인을 하고, 확인을 했으니 comment out 해 놓은 것일 것이고, 두번째 라인을 보면 connectionProviderFactory의 main()을 호출하고 있다. 아마도 context어딘가에 connection을 만들어 넣어두는 것이겠고.
저 main()도 ConnectionProvoiderFactory를 test를 위해서 만들어 둔 것일 텐데 다시 써먹고 있다. ConnectionProvoiderFactory를 Test클래스를 만들어서 test를 했다면 이 클래스를 test하는데 Connection을 얻기 위한 코드를 어딘가에 중복해서 작성해야만 했을 것이다.

이 두라인만 보고도 "오호-"하는 소리가 나왔다.

그다음. 로깅.
apache logging을 사용하고 있다면, 매 클래스에서 static final로 logging클래스를 정의하는 것은 교과서적인 방법이고, 또 귀찮은 방법이다. properties(또는 xml)파일을 수정해야 하는 것도 그렇고.
Log.logToStderr = true;
저렇게 해서 모든 로깅을 볼 수 있다면.
여기서는 "으음-"하는 가벼운 신음소리가 나온다.

또, 저 소스를 보면 runnablequary.xxxProcessor라고 하는 클래스는 SessionCaching이라고 하는 interface(아마도 interface일 것이다.)를 implements하고 있다. 그리고 main은 똑같은 코드를 두번 사용한 것을 보면, caching기능을 테스트 하고 있는 것이 아닌가 생각된다. 아마도 caching을 만들어서 사용하는 것 같은데, 나라면 (공개되어 많이 사용하는 pooling라이브러리 사용을 선택했겠지만,) 그건 아마도 시스템을 다 만들어 놓고 난 뒤의 Performance개선을 위해서 였을 것이다.

이 클래스는 init()한 뒤에 run()하는 것이 주된 function으로 보이고, init()의 parameter로 QueryParameter계열의 클래스를 use하고 있다. 이 parameter를 만들 때를 보면 Dao나 BL을 직접 부르지도 않고 UserFactory로 한 번 더 wrap해서 static으로 호출하고 있다. 이것도 Cool!
Exception이 발생할 가능성도 처리해야겠지만, 여기는 테스트 목적이기 때문에 OK.

아마도, 이 desktop.jpg는, 길다란 스크린을 보여주고 싶은 것이 아니라, 작성하고 싶은 소스를 보여주고 싶었는지도 모르겠다.

나중에 시간이 나면 이 소스와 관련해 뭔가 있을 지, 더 찾아봐야겠다.