Java 그쪽 동네는

java 그쪽 동네는
플랫폼 연구개발실
임도형 책임

본 문서의 목적
저쪽 java 쪽의 개발 트렌드가 어떠한지 소개

java의 개발 대상
임도형의 주관에 의한 비율
웹 UI의 업무 시스템: 80%
jsp: 60
business logic: 20
기타: 20
솔루션 개발: 10%
기타: 10%
eclipse plugin, app on mobile

java 개발자를 구할 때의 keyword
java : 버전은 따지지 않음. 단지 연차만 3년이상이면 됨.
eclipse : 굳이 언급하지 않음. 몰라도 쉽게 배울 수 있고.
dbms: oracle, mysql등. 프로그래머 인데도 알아서 서버 설치하고, 접속하고, sql 작성하여야 함. 대형 프로젝트(팀 30인 이상) 정도되면 DBA가 따로 배정됨.
OR Mapping 툴 : hibernate, iBatis등. java와 동급 정도로 따짐. 특히 경력자 일 경우 모르면 곤란.
framework : spring 등. 초급이 아닌 이상 모르면 곤란.
WAS : tomcat, jeus, web logic 등. 아예 기본으로 생각함. 따로 언급하지 않음.
html, java script, jsp, Servlet : 역시 기본으로 생각함. 모르면 바보.

프로젝트에 java 개발자가 투입되면
보통 개발 환경은 이미 정의되어 있다.(by PM or TL)
WAS, framework, eclipse configure, jsp template, SCM
TL들은 자신의 경험으로 사용할 환경을 결정/셋업한다.
어떤 DBMS
어떤 WAS
어떤 framework
어떤 OR Mapping
트랜잭션 관리 방법

일반 개발자가 고민할 것은
오직 로직 구현
기타의 사항은 신경 쓰지 않는다.
이중화
성능
모니터링
당연히 어떤 기반 위에서 로직을 구현하는 것을 당연히 여긴다. 보통은 WAS
웹 시스템이 아니더라도 Jboss같은 AS 기반의 개발을 당연히 여긴다.

Eclipse
IDE 없이 개발하는 것은 상상도 못함.
90% 이상이 사용하는 개발 툴
수많은 plugin
Eclipse 자체는 IDE의 이름이라기 보다는 plugin이 구동할 수 있는 플랫폼이다.
그래서 java 쪽의 수많은 툴들은 eclipse를 기반으로 하고 있다.
이 말은 plugin만 개발한다는 것.

왜 Eclipse를 사용할까?
임도형이 vi에서 eclipse로 넘어온 이유는 오로지 refactoring때문. 그것도 오직 renaming.
기타 이유
entity navigation(클래스, 메소드)
decompile
code assistance
기타 툴과 연동됨
svn, maven, track
WAS, DBMS와도 연동됨

개발자의 필수품
예전에는 개발했던 프로젝트, 라이브러리 등을 가지고 다녔다.
그런데 요즘은 빈손으로 다닌다.
나만의 노하우는 이제 거의 쓸모가 없어졌다. 왠만한 건 검색으로 10분이면 찾는다.
대신 인터넷 없이는 개발이 거의 불가능하다.

open project
정말 필요한 것이 인터넷에 다 있는가?
노하우는 거의 다 있다. 특히 문제 상황의 경우는.
그리고 게다가 필요한 기능 구현도 대부분 다 있다. 왠만한 것은.
물론 품질이나 완성도는 차이가 많이 나지만.
TL의 중요한 역할 중 하나는 필요한 기능의 프로젝트를 찾아서 검증하고 본 프로젝트에 적용하도록 가이드 하는 것이다.
이런 개발 트렌드는“OPEN”의 덕이다.

must on platform
아무도 맨땅에서 개발하려 하지 않는다.
어떤 플랫폼 위에서의 개발을 당연하게 여긴다.
새로운 개념이 등장하면(SOA, XML, Cloud Computing 같은) 구현체를 기다리고, 쓸만한 프로젝트가 오픈되면 열광하여 가져다 쓴다.
java 개발자들 중에는 그런 early adapter 들이 있다. 이들은 blog, 책, 강좌 등으로 소개를 하고 꽤나 북적된다.

경향
그냥 코딩만 잘해서는 먹히질 않는다.
삽질 하지 않을 괜찮은 방법을 아는 것이 중요하다.
그러다 보면 단지 framework 뿐 아니라 IT의 다방면의 것들에 신경을 쓰게 된다.
개발 방법, agile, XP, 새로운 언어, Ruby on Rails, 개발 툴, Groovy
그리고 실제로 적용해 보면 효과가 있음을 느끼고, 더더욱 효율에 대하여 관심을 더 갖는다.
코드 자체 보다도 그 외의 것에 의해 생산성이 좌우된다는 것을 느끼고 있다.

agile, XP
삽질 하지 말자는 것.
특정 언어와 관계없다.
그런데 java 개발자들이 더 선호하는 것은, 언어의 차이 보다는 경향의 차이이다.
더 효율적인 방법을 찾는 경향.

트랜드에 민감하다.
web 2.0
UML
OOP
design pattern
refactoring
SOA
web service
이것들의 공통점 역시 효율이다. 혹은 재사용.

그 외 모습들
대충 대충 코딩해도
성능 보다는 가독성이 중요하다.
쉬운 컴파일
컴파일 환경이 그래도 쉽다.
대부분은 TL이 알아서 준비해 준다.
환경따라 변하지 않는
OS에 대한 고민하지 않는다.
그렇게 똘똘하지 않은
데이터 구조와 알고리즘이 프로그래밍이라고?

Spec and Implementation
스펙을 정하고
어디서는 그것을 구현하고
개발자는 구현한 것을 가져다 사용하고

suggest into spec
필요한 것은 제안하고
제안한 것은 spec이 되고
괜찮다 싶은 것은 java의 표준으로 포함된다.
이러한 것이 open project 성황의 근원 아닐까

java쪽의 대형 벤더
벤더들
IBM
Oracle
Sun
Bea
Red Hat
전부 java에 굵직하게 관련되어 있다.
전부 WAS 하나 정도는 가지고 있다.

java만 있는 enterprise system
기업의 신규 개발되는 시스템은 모조리 java이다.
왜?
일정 수준의 품질이 보장되니까
개발자에 의존적이지 않는 품질
단지 java라는 언어 특성 때문에?
그것 보다는 platform위의 개발이기 때문에.
남은 것은 얼마나 더 효율적으로혹은 더 큰 생산성인가이다.

성능이 중요한 곳도 java?
java 자체가 느린 것은 사실이다.
그러나 낮아진 하드웨어 가격이 그것을 커버한다.
성능을 100% 개선하기 보다는 하드웨어 100% 증설이 더 싸다.
심지어 성능을 위한 가독성 없는 코드는 죄악 시 되기도 한다.
보통 성능 테스트 시에 튜닝으로 해결한다.
튜닝 포인트 3곳 정도의 개선으로 100% 성능 향상

java쪽에서 좋은 코드란
첫 번 째가가독성이다.
축약 금지
큰 블럭 금지(최대 50 line정도)
큰 클래스 금지(최대 10 method 정도)
중첩 블럭 금지(최대 3단계 정도)
if 지양(if 보다는 strategy class로)
주석지양(코드자체로 이해가 되게)

java 그리고 c/c++
java가 c/c++보다 낳다고는 절대 말할 수 없다.
그러나 긍정적인 경향의 차이는 확실히 존재한다.
platform위의 개발이란 것에 기인
그러한 경향의 것은 언어와 도메인과 관계없다. 괜찮으면 가져다 적용하면 그만이다.

경향이 그렇다고? 현실은…
SI쪽에서는 철저히 개발자를 돈으로 본다.
몇년차는 얼마라고 정해져 있다.
초급 : java 언어는 조금 알고, framework도 모르고
중급 : 언어 문제 없고, framework도 문제 없고
고급 : 설계가능하고, 개발환경 잡을 수 있고
실제는 3년은 뻥튀기 한다.
정해진 플랫폼에서 개발하기 때문에
잘하고 못하고의 생산성 차이가 별로 없다.
낮은 생산성을 기반으로 한다. 플랫폼이 커버한다.
생산량은 업무량과 거의 비례한다.(야근, 주말 필수)

Special Thanks!
Are There Any Other Questions?

http://aploit.egloos.com	198
http://www.slideshare.net	111
http://www.hanrss.com	7
http://www.egloos.com	1

Java 그쪽 동네는

by Dohyoung Rim on May 13, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

4 Embeds 317

Statistics

Java 그쪽 동네는 — Presentation Transcript