'프레임워크'에 해당되는 글 2건

  1. 2009.01.06 Spring in Action SE, 컴퓨터 언어로 짓는 문학 작품.
  2. 2008.10.10 소프트웨어 개발자의 로망, 아키텍트(Architect)! (12)
2009. 1. 6. 22:13

Spring in Action SE, 컴퓨터 언어로 짓는 문학 작품.

Spring in Action SE는 올해 6월 전역하자 마자 Adobe Flex3 Traning From the Source와 더불어 인터넷으로 바로 구입했다. Struts in Action를 통해 자바 웹 프레임워크에 대한 개념을 익히고, 군 복무 시절 삼성SDS의 국방 프로젝트에 곁다리 담그듯이 참여하면서 Struts와 Spring에 대해 조금 맛보았기 때문에 영어 원서라는 것을 무릎쓰고 구매했다. 구입했을 당시는 5만원 3천이었는데 지금은 환율 때문에 가격이 안드로메다로 가고 있다. -_-;

2008년 6월 구입 내역


지금 구입하려면...OTL

우리나라에 번역서는 ITC를 통해 지난 12월에 나왔다. ITC출판사는 웹사이트 최적화 기법 책을 통해 처음 접했는데 표지가 상당히 이쁘게 잘 만들었다는 느낌이 강했다. Outsider님이 쓰신 리뷰 참조. 가격은 3만원대이다. 번역평도 꽤 좋은 편인 것 같아서 이해하는데 큰 무리는 없을 것 같다. 이에 대해 Max님이 쓰신 포스팅을 참조하라.

[서적] Spring in Action SE 번역서가 나왔다.

지금은 잠시 책장을 덮어두려고 한다. 일부 전사(Enterprise) 내용은 특정 기능에 치중하여 나중에 읽고 싶다. 마지막 다른 웹 프레임워크와의 연동 챕터도 제외했다. 내가 읽은 챕터들은 아래에 굵은 글씨와 연두색 배경색으로 되어 있는 부분들이다.

Part 1 Core Spring

Springing into action
Basic bean wiring
Advanced bean wiring
Advising beans

Part 2 Enterprise Spring

Hitting the database
Managing transactions
Securing Spring
Spring and POJO-based remote services
Building contract-first web services in Spring
Spring messaging
Spring and Enterprise JavaBeans
Accessing enterprise services

Part 3 Client-side Spring

Handling web requests
Rendering web views
Using Spring Web Flow
Integrating with other web frameworks

이 책을 읽기 시작한 것은 9월 1일 블로그칵테일에 입사하면서 이다. 그런데 퇴근하면 저녁 9시를 향하기 일쑤라 안그래도 두꺼운 책장이 잘 넘어가지 않았다. 그래서 9월 말부터는 프린팅을 해서 전통 제본을 수작업으로 만든 뒤 출퇴근 지하철 안에서 읽었다. 형광펜으로 밑줄도 그어가며.(집에 돌아와서는 복습하면서 원책에 밑줄을 다시 그었다.)
1-3챕터는 집에서, 4챕터부터 7챕터, 13챕터 부터 15챕터까지는 지하철이나 걸으면서 읽은 부분이다. 지금 생각하면 놀라울 뿐이다. 출퇴근 시간에 이렇게 많이 읽을 수 있는지! (약 3개월 반동안 A4 400페이지 가량을 이동하는 시간에 보았다.)
전통 제본철하는 방법은 간단하다. 일정 간격으로 송곳이나 게시판 압정같은 것으로 구멍을 뚫은 뒤 실을 꿴 바늘로 이리저리 감아주면 된다. '이리저리'에 대해 더 알고 싶으신 분은 호작질님의 전통제본 방법 - 실로 꿰매기로 이동. 출력은 fineprint라는 유틸리티를 사용하면 편하다. 나는 앞(4,1), 뒤(2,3) 식으로 출력한 뒤 A4 한 장 씩 반으로 접어서 제본했다.
포스팅의 주제가 '이동하면서 책 읽기'에 대해 많이 논한 것 같다. 포스팅 제목을 보고 이 글을 읽고 계시는 분들을 위해, 낚시 글이 되지 않기 위해서, 위에서 내가 읽은 챕터들 중 가장 마지막에 읽은 챕터인 7. Securing Spring, Summary의 웹 프레임워크 Spring의 정체성 잘 소개한 한 문장을 소개하고자 한다.
그것(보안)은 스프링의 철학인 느슨한 결합도, 의존성 주입, 관점 지향 프로그래밍에 기반한다고 할 수 있다.
...that is based on Spring's philosophy of loose coupling, dependency injection, and aspect-oriented programming.
웹 프레임워크에 대해 생소하거나 디자인 패턴에 대해 미숙한 배경지식을 가지고 있다면 조금 난해할 수 있는 책이겠으나, 해커(hacker)의 덕목인 조금의 인내를 가지고 매진한다면 자바라는 컴퓨터 언어를 통해 이 시대의 훌륭한 아키텍처(프로그래머)들이 이룩한 스프링의 묘미 - 어쩌면 컴퓨터 언어로 지은 문학 작품이라고도 할 만한 - 를 온몸으로 느낄 수 있을 것이다.

'컴퓨터 과학 > Java' 카테고리의 다른 글

JCO 컨퍼런스에 다녀왔습니다!  (2) 2009.03.05
Comment 0
2008. 10. 10. 10:40

소프트웨어 개발자의 로망, 아키텍트(Architect)!

소프트웨어 개발은 그 학문적 특질이 유사한 건축과 연관관계를 맺고 있다. 소프트웨어 개발의 특정 조건에서 발생되는 규칙적인 문제를 해결하기 위한 디자인 패턴도 이런 건축학에서 비롯되었다(건축학의 역사가 더 오래된 만큼 당연한 결과.). 건축 설계자를 영어로 아키텍트(Architect)라고 하듯 소프트웨어 개발 역할에도 아키텍트가 존재하는데, 여기서 그 역할을 소개하고자 했으나, 좋은 책이 있어 떠중이의 말은 줄이고 그 책의 목차나 소개하고자 한다.

책, 아키텍트 이야기(야마모토 케이지 저)의 목차


책을 읽어볼 요량이 없는 분들을 위해 아키텍트의 두가지 측면만 간단히 요약, 설해보도록 하겠다. 첫째는 개발 단계별로 필요한 공수고, 둘째는 단계별 업무 분야다.

소프트웨어 개발 단계를 크게 4단계(요구분석, 설계, 구현, 테스트), 개발 역할을 6 분야(요구분석 담당자, 아키텍트, 프로그래머, 인프라 담당자, 테스트 담당자, 프로젝트 관리자)로 나누었을 때 그 공수는 다음과 같다.(숫자가 높을수록 들어가는 공수(工數)가 많다.)

 요구분석 담당자
5
3
2
1
 아키텍트 3
5
2
1
 프로그래머  1 3
5
3
 인프라 담당자
 2 1
1
2
 테스트 담당자
3
1
4
5
 프로젝트 관리자
 3 2 2
3
  요구분석 단계
설계 단계
구현 단계
테스트 단계

아키텍트의 요구분석 단계에서는 프로젝트 관리자의 비지니스 마인드로 프로젝트를 바라보는 능력이 아키텍트에게도 요구되며, 요구분석 담당자에게는 기술 전문가의 입장에서 조언하는 조언자의 역할을 수행한다. 여기서 아키텍트는 기술 관련 위험요소를 개발 초기에 해결 혹은 해결을 위한 계획을 수립해야 한다. 비기능 요구사항(사용자가 사용하는 기능 외 시스템이 요구하는 기능)도 적극적으로 제안할 필요가 있다.

설계 단계에서 아키텍트는 개발 명세 설계에 참여하게 되는데 명세 설계 주 담당자와 더불어, 기술에 편중되지 않고 효율적인 사용자 중심 설계가 되도록 노력해야 한다. 그러나 주요 업무는 역시 '아키텍처 설계'이다. 아키텍처는 기술 문제를 정리해야 하므로 초기에 검토되어야 하고, 요구분석 단계에서 나온 요구사항을 해결할 수 있어야 한다. 이 설계서는 개발자를 위한 최초의 문서가 되며, 이후 프로젝트 산출물의 표준양식이 된다. 따라서 개요를 확실히 이해해야 기술 요소를 정확하게 설명할 수 있고, 팀원과의 의사소통을 원활히 하여 설계서에 명시된 바에 따라 제대로 된 구현을 할 수 있다.

구현 단계에서 아키텍트는 실제로 구현하는 프로그래머의 중개자 역할을 수행하게 된다. 설계된 아키텍처를 적용할 수 있는 프레임워크를 제공하여 아키텍처가 효과적으로 지켜질 수 있도록 하고, 팀원의 수준에 맞춰 역할을 분담한다. 그리고 팀원들의 프레임워크에 대한 적극적 참여를 동기 부여하여, 아키텍처나 프레임워크에 대한 피드백을 받도록 하고, 프레임워크가 팀원들의 수준과 프로젝트 목적에 맞춰지도록 조율을 한다.

테스트 단계에서 아키텍트의 실질적 공수는 적다. 테스트의 주인공은 테스트 담당자이기 때문이다. 하지만 아키텍트는 구현 단계에서와 같이 중개자로서 팀의 윤활유 역할을 해야한다. 나아가 앞의 설계 단계에서 단위 테스트와 결합 테스트를 효율적으로 진행할 수 있는 아키텍처를 테스트 담당자와 함께 구현 단계 전에 미리 생각해보는 것도 좋은 방법이다.

10년 뒤에도 기술자로 일하고 싶은가? 소프트웨어 설계를 넓은 안목으로 보라. 소프트웨어 구현(코딩)이 즐거움을 주는 것은 사실이지만, 개발이 취미거나 프리랜서에 해당하지 않고, 오래 회사 밥을 먹으며 개발을 하고 싶다면, 숲을 보는 더 큰 즐거움을 좇는 혜안이 필요하다.

Matrix - Neo vs. Architect


Comment 12