Rod Johnson의 J2EE Development without EJB를 읽으면서 끄적이기 계속…

저자는 두번째 챕터에서 앞 장에서 제시한 6가지 core values에 대해서 좀 더 상세하게 설명하면서 J2EE w/o EJB에서 추구하는 목적을 분명하게 제시하고 있다.

전통적인 J2EE개발방식(with EJB)의 문제점들은 이 책의 전반에 걸쳐서 지속적으로 지적되고 있다. 어떤 이는 EJB를 너무 까는 것 아니냐며 불평하는 것도 들었지만 그래도 냉정하게 볼 때 사실이니까. 깔 건 까야지.

1. 생산성

전통적인 J2EE 개발에서 생산성 문제를 해결하기 위한 방법으로 등장한 대표적인 것은 code generation이다. 많은 IDE나 xdoclet같은 툴들이 code generation을 통해서 EJB개발의 부하를 줄여주고 있기는 하다. 하지만 code generation기술은 그 자체로 필요악(EJB개발이라면)일 수 밖에 없다. 차라리 그런 땜방기술을 쓰는 것보다는 근본적인 아키텍처를 다시 고려하는 것이 마땅하다.

내 경험으로 볼 때 EJB개발시 IDE등의 code generation기능을 이용하는 것은 사실 매우 편하다. 다만 개발초기에만 편할 뿐이다. 그 후에 시스템이 복잡해지고 일정 부분이 지나고 나면서 생성된 코드들을 다루거나 건드리기 시작하면 많은 문제와 불편함이 발생된다.

JBuilder에서 JBoss용 EJB애플리케이션을 개발할 때 jboss plugin을 써서 J2EE-EJB DD를 생성하곤 했는데 그 jboss plugin은 round-trip에는 대책이 없는지라 각종 내가 추가 변경했던 DD의 내용들이 bean하나만 수정해도 한번에 날라가곤 했다. 이것을 막아보려고 별짓을 다해봤지만 뭐 뚜렸한 대책이 없었다.

Code generation으로 복잡한 아키텍처의 단점을 땜빵하려고 하지말고 그것을 쓰지 않을 수 있을 만큼 심플하고 유연한 아키텍처를 사용하도록 하자. 특히 중복되는 코드(code duplication)들 만큼은 절대 피할 수 있는 길을 찾도록 한다.

DB로부터 Entity bean과 관련 artifacts를 생성하는 것 또는 entity bean으로부터 DB schema용 DDL을 만드는 것. DAO자동생성, EJB DDs생성, XML interchange code생성. Service Locator & Business Delegate pattern을 따르는 각종 EJB 연동 코드 생성 또는 전체 J2EE stack을 한번에 생성하는 것(헉!). 그리고 각종 template 코드를 만들어 복제해서 쓰는 것 등은 모두 피할 수 있고 피해야만 하는 code generation기술이다.

가만히 생각해 보면 저런 방법등을 사용했던 것이 그저 당장 일을 쉽게 하려고 다른 대안이나 구조적인 부분에서 고민을 하지 않은 결과라는 생각이 든다.

MDA기반의 code generation기술(higher levels of abstraction)이 성숙해져서 언젠가 이상적으로 사용될 수 있겠지만 저자는 그런 날이 빨라도 10-15년 후에나 올 것 같다고 한다. 헉!

Code generation과 같은 방법이 아니라면 J2EE개발생산성을 높이기 위한 어떤 방법들을 취해야 하는가.

저자는 3가지 면에서 생산성 향상을 위한 방법을 제시하는데.
첫째는 아키텍처이고 둘째는 문제에 대한 집중과 방법론 세째는 적절한 툴의 사용이다.

- 아키텍처

아키텍처면에서 보자면 결국 좋은 프레임웍-아키텍처를 선택하는 것이 제일 중요하다고 본다. 간혹 자체적으로 개발한 in-house 환경을 사용하려는 시도가 있는데 이는 경험적으로 볼 때 매우 위험한 선택이다. 상당한 시간과 돈과 시행착오에 대한 투자를 할 수 있을 여력이 없다면 이미 나와서 검증된 좋은 프레임웍과 기술을 선택하는 것이 바람직하다. 또 상용 애플리케이션서버에 번들로 제공되는 기술을 쓸 수도 있는데 이 것은 특정서버에 매우 오랜 동안 종속될 것이 분명한 경우일 때만 선택가능하다. 특히 표준에 나오지 않은 특정벤더의 추가 기술들은 향후 새버전에서 새로운 표준기술로 바뀌면서 더 이상 구버전의 기능들과 호환이 되지 않을 수 있음을 기억할 필요가 있다.

제일 좋은 아키텍처 선택은 open source기반의 검증된 프레임웍이나 또는 상용이라고 하더라도 표준을 잘 따르고 이 책에서 제시하는 그런 핵심가치들을 잘 지키는 제품을 선택해야 할 것이다.

제일 안좋은 방법으로는 아키텍처적인 문제를 무시하고 그냥 몸으로 땜빵하려는 것인데… 내 주위만 봐도 이런 경우가 적지 않은 것 같으니… 왜 사서고생일까!

- 문제에 집중하기와 적절한 방법론선택

어떤 개발프로젝트든지 그 것이 요구하는 핵심요구사항 – 풀어야할 문제는 선명하게 구별되어 질 수 있다. 그 외에 주변적인 것에 몰두하는 것은 프로젝트를 산으로 몰고가는 지름길일 것에다. 사용자가 뻔히 수백명이 전부인 – 그러나 비즈니스 로직은 복잡한 – 내부 인트라넷을 개발하는데 모든 것을 퍼포먼스 – 수백만이 사용하는 시스템에서 요구하는 – 에만 촛점을 맞춰서 매달린다면 그야 말로 삽질하는 것일 수밖에.

적절한 후보 기술-프레임웍 등이 결정됐으면 그 모든 기술이 사용되어지는 간단한 뼈대프로그램(skeleton application)으로부터 출발하는 것이 좋다. 대부분의 유명 프레임웍등은 자체적으로 제공하는 좋은 skeleton applications(codes)들이 여러 케이스에 맞춰서 제공된다. 다만 너무 완벽하게 만들어진 샘플프로그램 – petstore같은 – 은 가져다 사용하기가 오히려 더 부담이 될 수도 있으니 피하는 것이 좋을 듯 하다.

나는 내가 사용할 가능성이 있는 각 프레임웍-기술의 조합별로 간단한 skeleton application을 만들어서 저장해 두고 사용하는데 주로 처음 그 기술을 공부할 때 많이 만들어 사용한다. 후에 프레임웍이 버전업 되거나 또 새로운 기능이나 구조를 알게 됐을 때마다 이를 업데이트 해둔다.

방법론은 agile methogology들을 사용하는 것이 개발속도를 위해서 가장 이상적이겠지만 뭐.. 프로젝트 규모나 특성에 따라서 역시 가장 적절한 방법론을 선택하면 될 것이다.

- 적절한 툴

종종 자바개발자 중에는 툴을 사용하는 것을 무슨 죄를 짓는 것처럼 두려워하는 사람들이 있다. EJB개발을 어떠한 툴의 도움도 받지 않고 vi 하나가지고 다 하려 하는 개발자들도 보았는데 집에 가면 부싯돌을 가지고 장작을 때서 밥을 해먹을 사람들이다. 툴을 사용하지 않는 이유가 툴을 쓰면 그 아래 돌아가는 기술에 대해서 무지해지기 때문이라고 하는데 – 그러면서 꼭 VB개발자를 걸고 넘어진다. VB개발자는 프로그래머도 아닌가? – 그럼 그 기술에 익숙해 지고 나서도 계속 툴을 쓰지않고그렇게 개발하는 이유는 뭔가? 자신들의 비효율적인 개발방법으로 수많은 피할 수 있는 잠재적인 오류들을 생산해 내면서 고객의 돈과 시간을 낭비하고 있다는 것을 왜 인식하지 못할까.

물론 툴에만 의지해서 기술을 등안시 하려하는 사람들도 문제이다. 또는 적절치 못한 툴을 선택해서 – 또는 특정툴에 대한 집착이 너무 강해서 – 문제가 될 수도 있다. 바른 툴을 선택해서 전체 개발프로세스에 걸쳐서 익숙해지도록 훈련하는 것이 필요할 것이다.

IDE뿐만 아니라, unit testing을 위한 툴, build tool, xml editor, source control system등의 선택도 중요할 것이다. 나도 notepad + dos command로부터 시작해서 다양한 자바툴들을 사용해왔는데 지금 가장 익숙하고 편한 툴을 eclipse + 각종 plug-in이다. 메모리를 좀 많이 먹는 것이 좀 불만이지만 그 외엔 대부분 만족스럽다. 좀더 많은 종류의 plug-in들이 개발되어지고 편리하게 이용되기를 바랄 뿐이다. 사실 MS의 Visual Studio만큼 생산성이 높고 편리한 IDE는 아직 경험해 보지 못했다. 그 면에선 .NET개발자들이 부러울 따름이다.

2.. OO
OO는 J2EE보다 중요하다. OO의 탈을 썼으나 OO가 아닌 것들을 배제해야 한다. 그것을 저자는 fake object라고 부르는데 대표적으로 DTO, RDB테이블에서 생성되어진 Entity bean이나 persistent object, 또는 getter/setter만 있고 behavior가 없는 persistent object를 꼽는다. 대안이 없는 것이 아니라면 이런 fake object들은 피하라.

인퍼페이스 프로그래밍. 아무리 강조해도 지나치지 않다.

3. 비즈니스 요구사항의 중요성

고객이 요구하지도 않은 가상의 요구사항(phantom requirement)에 매달리지 말자. J2EE계에서 유행한다고 꼭 필요없는 기능을 구현하려는 것은 피해야 한다. 유행이라고 필요없는 것을 만드는 데 낭비를 할 것은 없다. 실력자랑이나 개발단가를 올리기 위해 오버스펙을 끌어들이는 짓은 이제 그만 하도록.

4. 기술과 아키텍처의 검증과정(empirical process)의 중요성

가능하면 프로젝트 시작 이전에 그게 아니라면 프로젝트 초반에 하도록 하자. 거의 10년전의 이야기다. 모대기업 SI업체에서 긴급 요청이 왔다 (그때 나는 주로 망친 프로젝트 막판 해결사로 유명한 한 팀에서 일을 했다) 일년여간 개발한 시스템이 막판에 테스트를 들어갔는데 오버스펙으로 인해 시스템이 부하를 감당 못하고 쓰기만 하면 뻗는 것이다. C/S시스템이라 서버만 늘린다고 되는 것도 아니고 2만여개의 클라이언트를 다 업그레이드 할 수도 없고 프로젝트 마감 두달을 남겨놓고 난리가 났다. 결국 그 업체가 처음에 검증도 없이 너무 무리한 기술환경을 도입한 것이 문제였다. 최적화를 하기에도 만든 시스템이 너무 엉망이었고 결국 남은 두달동안 우리팀에서 기존 개발한 것을 완전히 새로운 기술로 포팅하는 작업을 해서 겨우 시스템을 안정화 시켰던 기억이 난다.

많은 프로젝트들이 프로젝트가 끝나가는 시점 – 또는 오픈하고 나서야 – 선택한 아키텍처의 성능이나 기타 문제점을 발견하고 한다. 그 개발자나 아키텍트는 그래도 이게 외국에서는 알아주는 좋은 시스템인데.. 또는 세미나에 갔더니 강사가 이걸 쓰면 좋다고 하던데.. 따위의 핑계를 댄다. 다시 말하지만 누구도 믿지 말라. 책도 믿지 말고 벤더가 직접 또는 투자해서 개최된 세미나나 컨퍼런스 강사들의 말은 절~~~대로 더 믿지 마라. 영업사원의 말은 더더욱 그렇고 인터넷 – 블로그에 올라온 개인경험담이나 추측성 기사나 글은 더더욱 그렇다. 믿을 수 있는 것은 자신의 검증과 그 결과 뿐이다. 성능에 대해서 묻고 싶거등 컴퓨터에게 직접 물어보도록.

개발초기 또는 그 이전에 vertical slice를 만들어서 그 아키텍처를 반드시 검증해보도록 하자. 모든 경우를 다 만족할 수 있는 가장 이상적인 아키텍처란 없다. 자신의 요구를 충족할 수 였는 아키텍처는 스스로 찾아서 검증해보는 수밖에.

갈수록 J2EE계에선 실력있는 architect의 필요성이 절실해 진다. 하지만 특정 기술만 선호하는 – 책만 믿고 자신의 눈으로 확인해보려하지 않는 – 그런 시스템 설계자들은 그만 좀 사라져줬으면 하는 바람이다.

Related posts:

  1. J2EE Development without EJB (4) – The Simplicity Dividened
  2. J2EE Development without EJB (3) – Architecture
  3. J2EE Development without EJB 정리는 이만
  4. J2EE Development without EJB (5) – EJB, Five Years On
  5. J2EE Development without EJB (1) – Why "J2EE Without EJB"?
  6. J2EE Development without EJB (6) – Lightweight Container & IoC
  7. SpringFramework vs. J2EE?

Facebook comments:

to “J2EE Development without EJB (2) – Goal”

  1. 초초초초초보로 개발자를 꿈꾸는 신참입니다. :)
    2번의 objective oriented에 대해 이해를 도와주실 수 있나요?
    (DTO와 같은 소스코드를 인터페이스로 강제성을 주어라라는 말씀으로 이해를 했으나
    명확한 이해가 가질 않네요;;)
    경험적인 부분에서 많이 모자란 신참으로 이해를 하고 프로그래밍을 하고 싶어 이렇게
    글을 남기게 되었습니다.

  2. Hi there could I indication some of the percipience from this entry if I minister to a relationship bankroll b reverse to your site?

  3. good articles

  4. thank you for share!

  5. You can check here
    [url=http://www.tshu8.com/member/uploadsiedit.php?/chloe-allocine-chloe-coupon-online.html]chloe allocine-chloe-coupon online[/url]
    chloe allocine-chloe-coupon online

  6. thank you for share!

  7. Click for info
    [url=http://www.melanconenergy.com/images/index.asp?/how-much-is-a-moncler-with-high-quality-and-wonderful-colors-2013.html]how much is a moncler-With high quality and wonderful colors 2013[/url]
    how much is a moncler-With high quality and wonderful colors 2013

  8. Look At This Site
    [url=http://bootssaleukonline.com]ugg boots uk sale[/url]
    ugg boots uk sale

  9. Pop Over HERE
    [url=http://cheapbaileybuttonoutlet.com]mini uggs[/url]
    mini uggs

  10. mbt m walk J2EE Development without EJB (2) – Goal » Toby’s Epril

Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha