2008/02/24 13:56
지난 토요일(16일)에 JCO에서 주관했던 '자바개발자컨퍼런스'를 다녀왔다.
오전 기조사는 가볍게 듣지 않고...이제는 유부남이 되어버린 친구 쫑아와 코엑스에서 만나, 점심을 같이 먹고 행사장으로 가보니.... 수많은 사람들이 행사장을 가득 채우고 있었다. O.O

작년에 비해 과하게 많은 개발자 숫자에 급 놀랐는데... 자세히보니 '무료이기에 편히 참석한 대학생들'이 대부분이었다. orz
일단 사람들을 뚫고 해당 세션장으로 들어가 자리를 잡고 열심히 발표를 듣기 시작했다.

당일의 느낌은 "미투"에 적어놓았기에 생략!!! 정리했던 내용만 기록하겠다.

1번세션 - 아키텍트로 가는길 : 동부 CNI , 과장 백용규

1. 성공하는 아키텍트의 길

아키텍트 고수 : 누구? 어떤 방법?, 경험?, 어떻게?, 어디?, 미래?

프로그래머 컴퓨터 사용자 (flow)

프로그래머 : 이제는 core 프로그래밍 기술(언어) 뿐만 아니라 web언어와 프레임웤을 알아야 한다.

컴퓨터 : 플랫폼의 구조 이해, 네트워크 저장장치 이용, 운영체제, 자료구조 + 알고리즘

사용자 : 시스템 연계 사용 증대 사내 시스템과 사외 시스템을 연계하여 정보처리 증대

아키텍트와 프로젝트 관리자

공통점 : 프로젝트 관리

차이 : 아키텍트 정보기술책임, 프로젝트 관리 프로젝트 관리

2. 아키텍트의 전성시대

프로젝트 참여자 : sw아키텍트, system 아키텍트, 데이터 아키텍트, 네트워크 아키텍트, 프로그래머, 비즈니스아키텍트, PM (아키텍트들이 의사결정을 한다)

Process / People / Technology

Process : 표준방법론 이해 및 프로세트 테일러링 수행

People : 초급/중급 엔지니어리딩 및 고객 요구사항 분석

Techmology : 고객 요구사항 해결을 위한 아키텍처 제시

S/W 아키텍처의 필요성

- 기술적인 결정을 내릴 때 비합리적인 결정을 내리는 경우가 많음

- 과거의 경험을 답습하는 경우가 많다.

- 프로젝트의 복잡성이 증가되고 관리가 되지 않으면 어느 순간 통제 불가

- 초기에 들어나지 않은 문제가 마무리 시점에 드러나는 경우가 많다

- 설계자가 본인의 역할을 수행 하지 못하는 경우가 많다.

3. 아키텍처 사례

분석 설계 개발 테스트

요구사항분석 컴포넌트 설계 컴포넌트 개발 컴포넌트 테스트

아키텍처 분석 아키텍처 설계, 아키텍처 평가, 아키텍처 상세화 아키텍처 반영 아키텍처 검증

* 아키텍처 평가는 설계단계에서 이루어져야 한다.

4. 아키텍트로 가는길 (결론)

- 프로젝트의 적극적 참여

- 정보기술의 트랜드 이해

- 명확한 객체지향 개념 이해

- 끝임없는 자기 개발 및 학습

- 문제해결능력 및 리더 마인드


2번세션 - 레거시 코드관리 전략 허광남

유지보수에 관한 방법론 필요, 소프트웨어 변경 주기가 짧아짐, 요구사항 변경에 따른 기민한 반응

남이 짠 소스 빨리 알아보기

1. 들여쓰기

2. code formatter

3. IDE 코드 네비게이션 기능 : F3 , ctrol+k, 형광펜

1. 팀원간 용어의 일관성

2. 변수명, 함수명의 기능에 따른 변경

1. 프레임워크 사용시 명명규칙은 절대적

2. Open Resources

3. Convention over Configuration

리팩토링

JSP javascript분리

Js java형식의 변환 (bean형식)

고려사항

1. 소스의 증가 : 선별적 js로딩 (dynamic js include)

2. 보안이슈 : 이중화 또는 서버단으로 이동

3. JS캐쉬 이슈

4. 서버단과 클라이언트단 혼재된 로직

Strategy pattern을 통한 테스트 자동화

시간이 걸리더라도 쓰이는 코드만 복사

- 긴 코드 주석제거

- 위키 같은 검색 가능한 메타 인프라 활용

도구를 이용한 refectore 활용

수정(refactoring)을 위한

Cover & modify : 가능하면 안전망을 만들어 놓는다 : div의 경우에도 overflow:hidden처럼..

코드풀기 : 리팩토링 : 소스추가하기 용이하도록 설계 변경

상속활용 : 클래스 복사는 줄일 것

사이드 이팩트 관리 : 테스트케이스로 자동 테스트 케이스 증가

3진 아웃제 : 1번은 가볍게 통과할 것

테스트주도를 위한 케이스 작성

Java의 경우 모델만 사용하여 짧고 쉽게 빠르게 테스트 가능하도록

Javascript의 경우 모델형 js include할 것. – 테스트를 위해서는 template를 작성하여 output을 보여줄 것


3번세션에는 잠깐 머리 식힐겸... 밖으로나와... 해피씨커님과 개밥님을 만나 아쑤크림을 먹었다. 짧은 시간이라 많은 이야기를 나누지는 못했지만, 이공계 대학생의 고민을 잠깐 들을 수 있는 자리였다. 아직 짧은 경험으로 도움을 주지 못해 마음이 무거웠고, 더 많이 노력해야 하는 이유를 가슴에 담았다.

4세션 - Walking in the pattern language – 최상훈(JCO 부회장)

Anatomy of Pattern

1. architectural Pattern

2. Design Pattern

3. Idiom (Micro Pattern) : Language Specification

Pattern적용시 큰 패턴을 먼저 적용하고 작은 패턴으로 점점 채워가는 방법으로 진행된다.

(Architectural Pattern -> Idiom)

Pattern Language

- Pattern Language define domain architecture

- Vocabulary Vs System Vs Language

- Common Vs Special

조합을 할수록 그 효과가 더 커짐 : MVC + Observer + Scoped Locking

More then One Solution to a Pattern

Iterator Vs Batch Method Vs Enumeration Method Patterns

Problem : Looping encapsulated process

상호 보안을 통해 보다 나은 pattern을 채택할 수 있다

Problem : I/O Event Handling

Acceptor/Connector Vs Reactor Vs Proactor

상호 경쟁적인 pattern이 존재 할 수 있따

Pattern은 혼합물이다. Pattern안에 subPattern이 존재하며.. pattern call하는 대상이 pattern이 될 수 있다.

Pattern sequences 의 조합

Pattern complements / Pattern Competition / Pattern Compound / Pattern Sequences

5세션 - 애자일에 대한 7가지 교훈 김창준

1. 삼위일체

- 성과 / 배움 / 즐거움

2. 품질

3. 왜 이걸 하는가

- agile을 위한 agile을 하는 사람들이 있다. But 장기적으로 좋지 않다.

- 분명하고 명확한 business모델을 목표를 잡는 것이 중요하다.

4. 우선순위

- 버려야 할 것은 버리자

- 가능한 coverage를 뽑도록 노력하자(Test Driven). 상대적인 cost 손해를 꼭 인지하고 전달하자.

5. 마음의 중요성

- 마음에 여유를 가지고 곰곰히 생각해보다.

- 마음과 마음이 소통해야 한다.

6. 생명의 느낌

7. 끝없는 길

-

* 즐거운 실패 : 실패하면서 교훈을 얻는 것. 그 교훈을 통해서 더 발전하도록 노력하는 것

) 버그가 발견되면 해당 버그의 집단(Factory)를 찾아서 그런 pattern을 없앨 수 있는 process를 만든다.


이번 자바개발자컨퍼런스에서 느낀점은 '개발자를 위한 축제'라고 했지만, 사실 '학생들을 위한 교육'정도의 내용이어서 실망했다. 물론 모든 발표가 부족한것은 아니었지만, 전체 구성이나 진행방식이 아직 많이 미숙하다는 생각이 들었다. JCO진행자의 말마따나 '각자의 일을 하는 짬짬히 준비한 컨퍼런스'인 만큼 부족한점이 있다는것은 어느정도 감수했음에도 드는 생각이었다...

특히나 과하게 많은 참석자와 비좁은 행사장의 문제, 진행시간의 미준수, 발표자의 지각.. 등은 지적을 안할 수 없었다. (개인적으로는 개발자들 서로 공감하는 주제로 가볍게 이야기를 나눌 수 없이 끌려다녀야만했던 타이트한 진행일정에 답답했다)

허나 풍부한 경험자가 자신의 고민을 발표의 형식으로 내비치고, 공유할 수 있는 이러한 자리는 (설사 위의 문제가 있다고 해도) 더욱 많이 생겨야 한다고 생각한다. 짧은 개발경력이지만.. 개발자들이 언제부터인가 open된 communication 창구를 필요로하고 서로 공유하며 보다 나은결과를 얻기위해 노력한다는것을 느끼고 있기 때문이다.
Trackback Address
http://babyp.net/trackback/486
by

pass://
 
184120
어제는 115명, 오늘은37명