내가  개발자로서 좋아 하는 책이 여러권있다.
굳이 내가 개발자임을 강조하는 것은, 현재 까지는 나의 생업이고(앞으로도 그렇겠지만) 아직까자 내가 가장 좋아하는 일이다.

새로운 것을 알아가고, 나의 손으로 창조하는 것이 비단 Programer 뿐이겠는가?
사람들의 눈으로 보이는 잣대로의 창조적인 작업이 아니라, 내손을 통해서 뿜어져 나오는 Code로 인해서 무언가가 만들어진다는 작가적 또는 예술가적인 희열을 비슷하게 경험할 수 있다는 것이 항상 새롭다.

내가 좋아하는 책 중에는 kant Beck이 저술했고, 국내에서는 김창준씨아 강규영씨가 옮겨서 소개진 테스트 주도 개발 이라는 책이있다. 처음 이책은 접하게 된것은 2005년 초이다.
TDD(Test Driven Development)라는 것은 나와 같이 일했던 연승훈이라는 분을 통해서 처음 알게되었다. 그래서 관심을 두기는 했지만 프로젝트에 적용하기에는 참 쉬지 않았다. Junit와 xUnit에 대해서 한국에서도 많은 사람들에게 소개되었지만, 정말 제대로 사용하는 사람들은 찾아보기 어려웠으며(이는 지금도 마찮가지이다.), 이를 적용한다고 해도 버그는 사라지지 않았다. 그리고 xUnint과 같은 Unit 테스트 툴들을 사용할 때, 정말 좋은지에 대해서 긍정하는 사람들도 그래 많지 않았다. (아마도 테스트 코드를 작성하는데, 추가적인 공수가 들었기 때문이라고 생각된다.)

지금도 많은 기업(어느 정도가 규모가 되는 회사)들은 jUnit를 도입하고, 이를 범용적으로 이용할 수 있도록 개발 프로세스와 개발시에 중요한 업무(?)로 정의해서 이를 지키도록 강요아닌 강요를 하고 있다.
개발자가 필요하다고 생각되면, 이를 사용하지 말라고 해도 몰래 사용할 것이다. 필요성과 함께 정확한 사용에 대한 교육이 당연히 뒤 따라 다녀야 한다. 이는 전적으로 나의 개인적인 생각이다. 아직도 책 하나 던져주고 담 주까지 익히라고 하는 과거의 관행은 없어졌지만 , 프로그램의 코드를 생산하는 일이 창조적이라고 생각한다면 반드시 피해야 한다. 하지만 좋은 스승은 그때 당시에 찾기 무척 어려웠다. 잡지(마이크로 소프트웨어)에서 간간히 소개가 되고는 있었지만, TDD도 xUnit은 이거라고 정의내려주는 사람은 좀처럼 찾아보기 힘들었다.

개발자에 의한,개발자를 위한 여러가지 것들에 관심이 많았던 나는 2005년 우연히 서점에서 김창준씨와 강규영씨가 번영한 켄트 백의 TDD책을 발견하고 바로 구매해서 보게되었다.
내가 좋안 하는 책들은 당연하게도, 여러번 반복해서 읽게 되는 책들인데, 이는 나의 필요에 의해서이다. 아니 내가 그들 만큼 똑똑하지 못하기 때문이다. 나는 지극히 평범하기 때문에, 나보다 앞선 선배들과 똑똑한 그들의 조언이 항상 필요하기 때문이다.

                                                    (바로 이책이다.)

내가 정확하게 2005년 3월에 그 책을 구입한 이후로 1년에 거의 2~3차례 이책을 탐독을 한다.  올해도 벌써 2번째 이책을 들여다 보고 있다. 아마 올해까지 거의 9~10회 정도를 본것 같다. 하지만 정확하게 그분(캔트 백)의 의도를 모르기 때문에 매년 이책을 반복해서 보는 것이다. 역시 나는 덜 똑똑한 사람이다. 남들은 쉽게 잘하는데...(백형 부러워요.)

하지만, 내가 이해하는 것은 TDD는 개발자 자신을 위한 것이기도 하지만, 프로젝트에 참여하는 모든 개발자와 테스트를 담담한 사람들과 결과물을 받을 사람들에게 반드시 필요하다.
이의 결과로 산출된 코드는 내가 담당한 코드의 결과를 예측케 하는데, 이는 코드의 명세서와 같은 역할을 한다. 일반적으로 잘 설계된 시스템과 Architect는 계약 관계를 어떤계 표시하는 가에 달려있다. 이는 설계자와 코드를 작성하는 개발자와 그리고 이를 테스트할 테스터와 최종 산출물을 사용할 이름 모를 사용자와의 약속이기 때문이다.

내가 작성할 코드의 결과를 바라보는 것은, 농부가 씨를 뿌릴때 가을에 거두어야 하는 작물이 무었인지 정확하기 아는 것과 같다. 이에 맞추어서 작물에 필요한 양분과 환경을 만들어주고 추수하는 것처럼 결과에 대해 명확히 알고 씨를 뿌리는 것은 정말 중요하다. (코드 명세서는 이래서 중요하다.) TDD를 통해 작성된 코드는 정확이 이래야 한다. 무엇을 정의하고 결과로 나오야 하는 것이 무엇이지 아는 것과 모르는 것의 차이는 분명하다.
따라서 똑같은 클래스에 대해서 테스트 할때 어떤 사람은 20개를 작성하는데 어떤 사람은 200개 가까운 테스트 코드를 작성하기도 하다. (아마도 한국에는 없을 것이다.)

이렇게 작성된 TDD의 테스트 코드는 리펙토링에도 유용하다. 리펙토링은 코드의 외적인 모습을 유지하면서 내부 구조를 변경하는 것이다. 이는 리펙토링은 결코 Architecture를 흔들어서는 안된고, 현재의 상태를 가장 최적의 상태를 만드는데 초점을 두어야 한다는 의미이다.

내가 켄트 백의 책을 프로젝트의 시작 초기에 항상 읽는 이유중에 하나는 내가 부족한 면이 가장 크지만, 그의 의도와 경험을 내것으로 만들고 싶은 이유 또한 크다.  테스트 코드를 작성하지 않고는 결코 불안해서 일이 안된다는 그의 말처럼, 중요한 것을 중요하게 여기면서 프로젝트에 임하고 싶기 때문이다.
사실 켄트백과 나는 다른 점이 나는 먼저 파란 불이 들어오면, 여기서 코딩을 시작한다. 그는 붉은 불에서 시작하지만, 나는 정말 붉은 불이 두럽다.

자신에게 맞는 코딩 스타일과 방법이 있다. 이를 무시하면 안된다. 나에게는 TDD와 Unit Test는 분명이 많는 방법이지만 아직 나만의 스타일은 없다. 매년 내가 그의 책은 읽는 것은 결국은 나의 스타일이 아직 없기 때문이기도 하다. (글을 쓰다가 느낀점이다. 글은 나를 바라보네 만드는 군.)
아마도, 내가 나만의 스타일을 통해서 이전보다 많은 부분이 채워지고 다듬어 진다면, 그의 책을 좀도 쉽게 볼수도 있을 것이다. (매년 볼때마다 꼭 이렇게 해야하는가에 대해 그에게 의문을 갖지만, 결국은 그도 매번 최선을 찾아서 일할거라 생각이 든다.)

드디어 Spring Dynamic Module 1.1이 발표되었다. 공식적으로는 미국 시간으로 7월 4일 어제였다. 그런데 바로 하루전인 7월 3일 Spring Dynamic Modules 1.0.3 정식 버전의 정상적으로 Release 되었는데 말이다.

Spring Dynamic Module의 정식이름은Spring Dynamic Modules for OSGi이다. 하지만 작년까지만 해도 우리들에게는 Spring OSGi라는 이름으로 더 잘 알려져 있었다. 그러나 OSGi Appliance의 공식적인 허가 없이는 OSGi라는 명칭을 사용할 수 없기에, 지금은 Sprig Dynamic Module로 사람들에게 소개된 것이다.

다운로드 가능한 위치는 아래와 같다.
    - spring-osgi-1.1.0-with-dependencies.zip
    - spring-osgi-1.1.0.zip

위 링크와 같이 두개의 버전으로 제공이 되는데, dependencies 라고 되어 있는 모듈은 참조를 하고 있는 관련 라이브러리(.jar)파일과 소스를 포함하고 있어서 개발 환경을 구축할 때, 손쉽고 시간을 절약하도록 되와준다. (개인적으로 추천)

Spring-DM 1.1버전과 1.0.3 버전이 하루 차이를 두고 동시에 발표되었는데, 이른 두 버전의 Feature가 다르기 때문이다. 쉽게 이야기 하면 1.1과 1.0의 Feature가 다른데, 1.0버전의 새로운 Feature는 다음과 같다.

The new 1.1.x series introduces several new features over the 1.0.x branch, such as:

* web support (Servlet, JSP, Taglibs) for OSGi applications
* Spring-MVC integration
* classpath scanning
* customization hooks for Spring-DM extender and web extender
* event notifications for OSGi service importers and application contexts
* refined OSGi proxy infrastructure
* 'greedy-proxy' functionality for OSGi collections
* integration with SpringSource Bundle Repository
* support for custom locations for Spring powered bundles
* pluggable mechanism for determining service dependencies
* access to native OSGi ServiceReference for OSGi importers
* new web sample
그리고 몇가지 버그 수정들이 수정됨.

위의 내용은 별도로 번역을 하지 않아도 이해가 가능할것이다. 기능에 대한 새로운 Feature들에 대한 설명인데, 이는 Spring Dynamic Module의 Reference Documentation 참고 하면 된다. (Chapter 3 What is new?)

그래도 간락하게 설명을 하면.
* OSGi상에서 Web Application 지원(Web Serport)
    - Appach Tomcat and Jetty와 같은 Container 지원
    - Spring-DM은 Servlet을 사용하는 WAR 파일을 지원하고,
    - JSP와 Taglib를 위해 거의 변경없이 바로 사용할 수 있게 해준다.
         ==> 참조 : Chapter 8, Web Support
    - Spring-MVC를 OSGi 환경하에서 지원함
        ==> 참조 :  Section 8.7, “Spring-MVC Integration”
    - Classpath Resource 탐색지원 :  classpath: and classpath*: 
       ==> 참조:  component scanning
   - 다양한 extender를 위해 default configurantin 을 쉽게 변경할 수 있음
   - Spring Application의 Lift cycle의 인지 아래 발생하는 Event를 받을 수 있음
   - Proxy Creation(생성)의 성능향상으로 번들의 Package wiring이 좋아짐.

일부에서, 스프링 DM을 이용한 프로젝트에 대해 우려를 많이 한다.
몇가지 알려진 문제들이 있는데, 이들은 이번에 발표된 1.1버전에서 많이 해결되었다.
가장 큰 문제는 Thread 지원과 Class Loder에 관한 부분들이었는데, 1.1의 지원으로 해결됨이 기쁜 일중에 하나이다.

역시 공부할 것은 자꾸 늘어간다. 스스로 실력없음을 항상 느낀다. 스프링의 방대한 소스를 보면서 더 많이 느낀게 되지만, 그래도 즐겁다.

<beans>
    <import resource="services.xml"/>
    <import resource="resources/messageSource.xml"/>
    <import resource="/resources/themeSource.xml"/>

    <bean id="bean1" class="..."/>
    <bean id="bean2" class="..."/>
</beans>