Archive for the ‘Java’ Category

Spring Dependency Injection 정리

Tuesday, March 25th, 2008

오늘부터 아침 스터디를 시작했다. 업무 시작 1시간 전에 나와서, 30분간 각자 책을 읽거나 인터넷에서 관심있는 아티클을 읽고 나머지 30분간 각자가 배운 내용을 공유하는 방식으로 진행하기로 했다.

오늘 공부할 주제로 “Spring Dependency Injection & Java 5″ 아티클을 선택했다. 최근 Spring 관련 정보를 너무 멀리 한 것 같아서 SpringSource 팀 블로그에서 최근 글 리스트를 살펴봤고, 이 글에 끌려서 읽기 시작했다.

간단히 내용을 요약하자면, Spring에서 DI를 구현할 수 있는 3가지 방법에 대해 설명이 되어 있고 각각의 장단점에 대해 잘 설명이 되어 있다.

가장 기본적이면서 많이 쓰이고 있는 방식은 XML 설정 파일을 통해 의존성을 설정해 주는 방식이다. XML 방식은 의존성 설정 파일을 한 곳에 모아서 관리할 수 있기 때문에 코드와 설정이 분리되어 있고, 중앙에서 전체 구조를 파악하기 좋은 장점이 있으나 Type Safety 체크가 어렵고 리팩토링 친화적이지 않은 단점 때문에 다른 대안을 필요로 한다.

XML 방식에 대한 대안으로 annotation 기반으로 코드에 의존성을 선언할 수 있는 방식이 Spring 2.5에서 소개되었다. 코드에 선언된 @Autowired annotation과 @Qualifier annotation을 사용해서 의존성을 삽입할 수 있다. 이 방식은 코드와 설정 파일이 한 곳에 있어서 의존성 파악이 쉬운 장점이 있지만 반대로 의존성 설정이 코드에 흩어져 있어서 전체적인 구조 파악을 방해할 수도 있다. XML 방식보다는 Type Safety를 더 정확히 보장해 주지만 복잡한 설정은 XML을 추가로 사용해야 하는 단점이 있다.

// In file OrderServiceImpl.java:

public class OrderServiceImpl implements OrderService {
    private OrderRepository orderRepository;

    @Autowired
    public JdbcOrderServiceImpl(OrderRepository orderRepo) {
        this.orderRepository = orderRepo;
    }

    // ...
}

// In file JdbcOrderRepositoryImpl.java:

public class JdbcOrderRepositoryImpl implements OrderRepository {

    @Autowired
    @Qualifier("myDataSource")
    private DataSource orderDataSource;

    // ...
}

code from ‘Introduction to the Spring Framework 2.5′ by Rod Johnson

마지막으로 현재 개발 중에 있는 JavaConfig 방식이 있다. XML로 설정하던 설정 파일을 Plain Java 코드로 구현하는 방식으로 완벽하게 Type Safety를 보장해 주며 코드와 설정 파일을 분리시켜 주는 장점을 그대로 가지고 있는 방식이다. RubyOnRails에서 설정 파일을 Ruby 파일로 구현하는 것과 같은 방식이라 할 수 있다.

@Configuration
public class MyConfig {
   @Bean
   public Person rod() {
      return new Person("Rod Johnson");
   } 

   @Bean(scope = Scope.PROTOTYPE)
   public Book book() {
      Book book = new Book("Expert One-on-One J2EE Design and Development");
      book.setAuthor(rod());  // rod() method is actually a bean reference !
      return book;
   }
}

code from ‘A Java configuration option for Spring’ by Rod Johnson’

결론적으로 세 가지 방식을 통해 DI를 구현할 수 있기 때문에 개발자가 상황에 맞게 적절한 DI 구현 방식을 선택할 수 있는 기회가 생겼다고 할 수 있다. 기존의 XML 방식은 복잡한 구조의 대형 프로젝트에서 여전히 유용하게 사용될 수 있을 것이며, 간단한 프로젝트에서는 annotation 방식을 통해 번거로운 XML 작업 없이 프로젝트 개발이 가능해졌다. 그리고 앞으로 발표된 JavaConfig 방식은 IDE와 연동해서 리팩토링에 친화적이며 Type Safety를 보장해 주는 이점이 극대화될 수 있을 것 같다.

언제 코드에 주석을 달아야 할까?

Friday, February 15th, 2008

코드에 주석을 어떻게 달아야 하는지 질문이 있어서 나만의 원칙을 정리해 보았다.

fantazic 코드 주석 원칙

  1. 주석보다는 테스트 케이스를 작성하자.
  2. 주석보다는 의미있는 이름을 사용하자.
  3. 필요하다면, 클래스와 메소드의 역할에 대한 주석을 남기자.
  4. API를 작성하는 경우, 주석을 충분히 자세하게 남기자.

최근에는 코드를 작성하는 시간이 줄어들었다. 실질적인 개발을 하고 싶지만, 기술 지원, 코칭, 설계 등 코드와는 동떨어진 업무에 더 많은 시간을 사용하고 있다.

그래서 배우고 생각한 것이 있어도 바로 실천으로 옮기지 못하는 경우가 많다. ‘주석을 다는 원칙’도 프로젝트에 직접 적용해 보면서 개선해 나가야 하는데 원칙만 있을 뿐 경험이 따라주지 못하고 있다.

최근 작성한 코드를 돌이켜 보니, 주석을 너무 무시했던 것 같다. 공통 모듈을 개발하면서 주석이 부족했으니 사용하는 개발자가 쉽게 가져다 쓰기 힘들었을 것이다. 무엇이든지 한번에 잘 되는 것은 없기 때문에 빠르게 자주 개선시켜 나가야겠다.

JCO 컨퍼런스 후기

Sunday, October 14th, 2007

올해 초에 진행됐던 Java 개발자 컨퍼런스에 이어서 이번에도 오픈소스를 주제로 컨퍼런스가 열렸다. 오픈소스 프로젝트 개발 경험, 오픈소스 제품 활용 방법, 오픈소스 지원 정책, 라이센스 문제 등 다양한 주제의 발표가 있었다.

가장 중점적으로 다뤄진 부분은 아무래도 Java 자체를 오픈소스화 하기로 결정한 이후 변화된 부분과 앞으로의 발전 방향에 관한 이야기였다. 이전에는 Sun이 중심이 되서 스펙을 정하고 Java를 만들었다면 앞으로는 오픈소스 커뮤니티를 중심으로 Java가 발전될 것이다. 특히 OpenJDK 등의 커뮤니티에 직접 참가해서 자신에게 필요한 기능과 스펙을 만들어갈 필요가 커졌다. Sun에서 운영하는 오픈소스 프로젝트가 glassfish를 비롯해서 여러 가지가 있기 때문에 개인적으로 관심을 갖고 참여할 생각이다.

Channy님이 발표한 모질자 그룹에 관한 이야기도 많은 도움이 됐다. FireFox 이전에 많은 실패가 있었지만 현재는 기술과 개념적인 성공 이후로 개발 커뮤니티 자체가 많이 발전한 상황이다. 특히 사용자들을 참여시키는 구전 마케팅과 javascript, css, xul(XML)만으로 개발되는 front-end 제품군은 정말 인상적이였다. 특히 사용자가 직접 플러그인을 제작할 수 있는 환경과 이 개발 방식이 Desktop Application에도 그대로 적용될 수 있기 때문에 활용성이 매우 컸고, 상용 프로젝트가 경제적 이유로 제품이 개발되고 개발이 중단된다면 오픈소스 프로젝트은 커뮤니티의 힘으로 지속적으로 새로운 제품을 만들어내고 진화해가기 때문에 매우 매력적이였다. (개인적으로 Channy님이 다음을 대표할 때보다 모질라를 대표할 때 편하게 느껴진다.)

그리고 이희승님이 발표한 JBoss 서버와 Remoting 프로젝트 관련 정보는 좀 더 넓은 세상에 대해 생각해볼 기회를 주었다. 사실 구글에 지원했다 실패한 후 새로운 도전을 못하고 있었는데 더 폭넓게 세상을 볼 수 있다면 여전히 기회는 무궁무진하다는 것을 알게됐다. 국내에서의 레퍼런스는 큰 도움이 안되겠지만 앞으로 좀 더 적극적으로 내 자신의 모습을 발전시켜 간다면 내가 원하고 좋아하는 일을 찾을 수 있다고 믿는다. 그리고 JBoss 내부 통신에 MINA 프로젝트가 적극적으로 사용된다고 하니 오픈소스의 힘을 다시 한번 느낄 수 있었다. (어제는 ‘Java work at home’으로 구글에서 채용 정보를 검색해 보았다. ㅋㅋ)

마지막으로 오픈소스에 관한 주제 속에서도 다음과 NHN이라는 포털 라이벌의 개발 환경이 각자의 개성을 발휘했던 것 같다. 사실 박재성님이 블로그 개발팀에 도입하고 있는 Agile 개발 문화가 NHN 전체의 모습은 아니지만 개발자가 바꿔갈 수 있는 NHN의 자발적인 힘을 충분히 보여준 것 같고, 박상길님의 발표한 역동적이고 매우 적극적인 다음의 개발자 문화 또한 상당히 인상적이였다. 구글과 MS와 같이 다음과 NHN이 앞으로도 선의의 경쟁을 통해 개발자의 천국으로 거듭날 수 있는 라이벌 관계로 남기를 바란다. (특히 박재성님 발표에 나온 것 중 몇 가지는 바로 실에 적용해볼까 한다.)