Java 그쪽 동네는

3,847 views

Published on

c개발자에게 java 개발자들의 성향을 설명하는 내용.

Published in: Technology
1 Comment
7 Likes
Statistics
Notes
No Downloads
Views
Total views
3,847
On SlideShare
0
From Embeds
0
Number of Embeds
383
Actions
Shares
0
Downloads
31
Comments
1
Likes
7
Embeds 0
No embeds

No notes for slide

Java 그쪽 동네는

  1. 1. java 그쪽 동네는<br />플랫폼 연구개발실<br />임도형 책임<br />
  2. 2. 본 문서의 목적<br />저쪽 java 쪽의 개발 트렌드가 어떠한지 소개<br />
  3. 3. java의 개발 대상<br />임도형의 주관에 의한 비율<br />웹 UI의 업무 시스템: 80%<br />jsp: 60 <br />business logic: 20<br />기타: 20<br />솔루션 개발: 10%<br />기타: 10%<br />eclipse plugin, app on mobile<br />
  4. 4. java 개발자를 구할 때의 keyword<br />java : 버전은 따지지 않음. 단지 연차만 3년이상이면 됨.<br />eclipse : 굳이 언급하지 않음. 몰라도 쉽게 배울 수 있고.<br />dbms: oracle, mysql등. 프로그래머 인데도 알아서 서버 설치하고, 접속하고, sql 작성하여야 함. 대형 프로젝트(팀 30인 이상) 정도되면 DBA가 따로 배정됨.<br />OR Mapping 툴 : hibernate, iBatis등. java와 동급 정도로 따짐. 특히 경력자 일 경우 모르면 곤란.<br />framework : spring 등. 초급이 아닌 이상 모르면 곤란.<br />WAS : tomcat, jeus, web logic 등. 아예 기본으로 생각함. 따로 언급하지 않음.<br />html, java script, jsp, Servlet : 역시 기본으로 생각함. 모르면 바보.<br />
  5. 5. 프로젝트에 java 개발자가 투입되면<br />보통 개발 환경은 이미 정의되어 있다.(by PM or TL)<br />WAS, framework, eclipse configure, jsp template, SCM<br />TL들은 자신의 경험으로 사용할 환경을 결정/셋업한다.<br />어떤 DBMS<br />어떤 WAS<br />어떤 framework<br />어떤 OR Mapping<br />트랜잭션 관리 방법<br />
  6. 6. 일반 개발자가 고민할 것은<br />오직 로직 구현<br />기타의 사항은 신경 쓰지 않는다.<br />이중화<br />성능<br />모니터링<br />당연히 어떤 기반 위에서 로직을 구현하는 것을 당연히 여긴다. 보통은 WAS<br />웹 시스템이 아니더라도 Jboss같은 AS 기반의 개발을 당연히 여긴다.<br />
  7. 7. Eclipse<br />IDE 없이 개발하는 것은 상상도 못함.<br />90% 이상이 사용하는 개발 툴<br />수많은 plugin<br />Eclipse 자체는 IDE의 이름이라기 보다는 plugin이 구동할 수 있는 플랫폼이다.<br />그래서 java 쪽의 수많은 툴들은 eclipse를 기반으로 하고 있다.<br />이 말은 plugin만 개발한다는 것.<br />
  8. 8. 왜 Eclipse를 사용할까?<br />임도형이 vi에서 eclipse로 넘어온 이유는 오로지 refactoring때문. 그것도 오직 renaming.<br />기타 이유<br />entity navigation(클래스, 메소드)<br />decompile<br />code assistance<br />기타 툴과 연동됨<br />svn, maven, track<br />WAS, DBMS와도 연동됨<br />
  9. 9. 개발자의 필수품<br />예전에는 개발했던 프로젝트, 라이브러리 등을 가지고 다녔다.<br />그런데 요즘은 빈손으로 다닌다.<br />나만의 노하우는 이제 거의 쓸모가 없어졌다. 왠만한 건 검색으로 10분이면 찾는다.<br />대신 인터넷 없이는 개발이 거의 불가능하다.<br />
  10. 10. open project<br />정말 필요한 것이 인터넷에 다 있는가?<br />노하우는 거의 다 있다. 특히 문제 상황의 경우는.<br />그리고 게다가 필요한 기능 구현도 대부분 다 있다. 왠만한 것은.<br />물론 품질이나 완성도는 차이가 많이 나지만.<br />TL의 중요한 역할 중 하나는 필요한 기능의 프로젝트를 찾아서 검증하고 본 프로젝트에 적용하도록 가이드 하는 것이다.<br />이런 개발 트렌드는“OPEN”의 덕이다.<br />
  11. 11. must on platform<br />아무도 맨땅에서 개발하려 하지 않는다.<br />어떤 플랫폼 위에서의 개발을 당연하게 여긴다.<br />새로운 개념이 등장하면(SOA, XML, Cloud Computing 같은) 구현체를 기다리고, 쓸만한 프로젝트가 오픈되면 열광하여 가져다 쓴다.<br />java 개발자들 중에는 그런 early adapter 들이 있다. 이들은 blog, 책, 강좌 등으로 소개를 하고 꽤나 북적된다.<br />
  12. 12. 경향<br />그냥 코딩만 잘해서는 먹히질 않는다.<br />삽질 하지 않을 괜찮은 방법을 아는 것이 중요하다.<br />그러다 보면 단지 framework 뿐 아니라 IT의 다방면의 것들에 신경을 쓰게 된다.<br />개발 방법, agile, XP, 새로운 언어, Ruby on Rails, 개발 툴, Groovy<br />그리고 실제로 적용해 보면 효과가 있음을 느끼고, 더더욱 효율에 대하여 관심을 더 갖는다.<br />코드 자체 보다도 그 외의 것에 의해 생산성이 좌우된다는 것을 느끼고 있다.<br />
  13. 13. agile, XP<br />삽질 하지 말자는 것.<br />특정 언어와 관계없다.<br />그런데 java 개발자들이 더 선호하는 것은, 언어의 차이 보다는 경향의 차이이다.<br />더 효율적인 방법을 찾는 경향.<br />
  14. 14. 트랜드에 민감하다.<br />web 2.0<br />UML<br />OOP<br />design pattern<br />refactoring<br />SOA<br />web service<br />이것들의 공통점 역시 효율이다. 혹은 재사용.<br />
  15. 15. 그 외 모습들<br />대충 대충 코딩해도<br />성능 보다는 가독성이 중요하다.<br />쉬운 컴파일<br />컴파일 환경이 그래도 쉽다.<br />대부분은 TL이 알아서 준비해 준다.<br />환경따라 변하지 않는<br />OS에 대한 고민하지 않는다.<br />그렇게 똘똘하지 않은<br />데이터 구조와 알고리즘이 프로그래밍이라고?<br />
  16. 16. Spec and Implementation<br />스펙을 정하고<br />어디서는 그것을 구현하고<br />개발자는 구현한 것을 가져다 사용하고<br />
  17. 17. suggest into spec<br />필요한 것은 제안하고<br />제안한 것은 spec이 되고<br />괜찮다 싶은 것은 java의 표준으로 포함된다.<br />이러한 것이 open project 성황의 근원 아닐까<br />
  18. 18. java쪽의 대형 벤더<br />벤더들<br />IBM<br />Oracle<br />Sun<br />Bea<br />Red Hat<br />전부 java에 굵직하게 관련되어 있다.<br />전부 WAS 하나 정도는 가지고 있다.<br />
  19. 19. java만 있는 enterprise system<br />기업의 신규 개발되는 시스템은 모조리 java이다.<br />왜?<br />일정 수준의 품질이 보장되니까<br />개발자에 의존적이지 않는 품질<br />단지 java라는 언어 특성 때문에?<br />그것 보다는 platform위의 개발이기 때문에.<br />남은 것은 얼마나 더 효율적으로혹은 더 큰 생산성인가이다.<br />
  20. 20. 성능이 중요한 곳도 java?<br />java 자체가 느린 것은 사실이다.<br />그러나 낮아진 하드웨어 가격이 그것을 커버한다.<br />성능을 100% 개선하기 보다는 하드웨어 100% 증설이 더 싸다.<br />심지어 성능을 위한 가독성 없는 코드는 죄악 시 되기도 한다.<br />보통 성능 테스트 시에 튜닝으로 해결한다.<br />튜닝 포인트 3곳 정도의 개선으로 100% 성능 향상<br />
  21. 21. java쪽에서 좋은 코드란<br />첫 번 째가가독성이다.<br />축약 금지<br />큰 블럭 금지(최대 50 line정도)<br />큰 클래스 금지(최대 10 method 정도)<br />중첩 블럭 금지(최대 3단계 정도)<br />if 지양(if 보다는 strategy class로)<br />주석지양(코드자체로 이해가 되게)<br />
  22. 22. java 그리고 c/c++<br />java가 c/c++보다 낳다고는 절대 말할 수 없다.<br />그러나 긍정적인 경향의 차이는 확실히 존재한다.<br />platform위의 개발이란 것에 기인<br />그러한 경향의 것은 언어와 도메인과 관계없다. 괜찮으면 가져다 적용하면 그만이다.<br />
  23. 23. 경향이 그렇다고? 현실은…<br />SI쪽에서는 철저히 개발자를 돈으로 본다.<br />몇년차는 얼마라고 정해져 있다.<br />초급 : java 언어는 조금 알고, framework도 모르고<br />중급 : 언어 문제 없고, framework도 문제 없고<br />고급 : 설계가능하고, 개발환경 잡을 수 있고<br />실제는 3년은 뻥튀기 한다.<br />정해진 플랫폼에서 개발하기 때문에 <br />잘하고 못하고의 생산성 차이가 별로 없다.<br />낮은 생산성을 기반으로 한다. 플랫폼이 커버한다.<br />생산량은 업무량과 거의 비례한다.(야근, 주말 필수)<br />
  24. 24. Special Thanks!<br />Are There Any Other Questions? <br />

×