소프트웨어 아키텍트가 알아야 할 97가지

Richard Monson-Haefel 저 / Eva Study 역

이 책은 흔히 일어나는 실수를 피하는 방법에서부터 능력있는 팀을 만드는 방법까지 모든 것에 대해 전 세계의 소프트웨어 아키텍트들로 부터의 조언을 실었다. 보통 소프트웨어 아키텍트들 또는 소프트웨어 아키텍트가 되기를 열망하는 분들을 위해서, 업계 최고의 소프트웨어 아키텍트들의 총체적인 조언들이 모여 있는 책이다.


도서 상세

분야: [비즈니스 & 테크놀러지, 프로그래밍]

출간일: Apr 14, 2011

페이지: 256

도서정가: 20,000 원

ISBN: 9788993827330

N 초급 B 초/중급 능숙 C P 숙련 E 전문
부가 정보


관련 도서

출판사 서평

최고의 아키텍트가 제시한 105개의 ‘the way to Architect’
각 분야 최고의 아키텍트의 통찰력을 한 권으로 만나보세요.


국내 아키텍트 8인의 글 수록!

소프트웨어 아키텍트로서 성공하려면, 비즈니스와 기술을 모두 익힐 필요가 있습니다. 이 책은 최고의 소프트웨어 아키텍트들이 무엇을 중요하게 생각하고, 어떻게 프로젝트를 접근하는지를 알려 줍니다. 만약 여러분의 경력을 돋보이게 하고 싶다면, '소프트웨어 아키텍트가 알아야 하는 97가지'는 꼭 읽어야 합니다.

소프트웨어 아키텍트들은 IT 에서 특별한 위치를 차지하고 있습니다. 자신들의 조직을 운영하는 것 뿐만 아니라, 서비스하는 비즈니스를 운영하는 기술과 소프트웨어 플랫폼을 알고 있는 사람들입니다. 우수한 소프트웨어 아키텍트는 동전의 양면인 비즈니스와 기술을 모두 터득할 필요가 있습니다. 이는 결코 조그만 도전 과제가 아니며, 이 책이 쓰여진 이유이기도 합니다.

이 책이 모든 소프트웨어 전문직을 위한 영감과 지침에 대한 좋은 시작점이 되기를 진정으로 바랍니다. 또한 소프트웨어 아키텍트들이 이 책을 읽고 오늘날 정보 기술의 가장 도전적인 직업으로 조언과 통찰력을 공유하기 위해서 관련 웹사이트를 사용하기를 원합니다.
이 책은 여러분이 읽어왔던 다른 책들과는 완전히 다릅니다. 48명 이상의 저자들의 합작품이며, 이들 모두 아무런 보상없이 소프트웨어 아키텍처에 대한 자신들의 생각과 충고를 제공했습니다. 어떤 측면에서 진정한 의미의 오픈 소스 서적입니다. 각 저자들은 자신들의 생각을 썼고, 그 내용들은 여러 저자를 통해 살펴보고 편집되었습니다. 그리고 나서, 가장 좋은 내용들을 모아 지금의 책이 되었습니다. 이 책은 개인의 지식이나 지혜보다, 코드로 공헌하는 오픈 소스 소프트웨어 프로젝트와 크게 다를 바가 없습니다

저자 소개

Richard Monson-Haefel : 수년간 엔터프라이즈 자바 빈즈, 코바, 자바 RMI 그리고 다른 자바 프로젝트 등의 설계자로 일해온 컨설턴트이다. '위스콘신 자바 사용자 그룹'의 설립자로 미국 컴퓨터 전문 잡지에 칼럼을 기고하였으며, 「자바 리포트 온라인」의 칼럼니스트이기도 하다. 또한 엔터프라이즈 자바 빈즈와 관련된 분산 컴퓨팅 기술에 대한 토론마당(http://www.monson-haefel.com)을 만들어 운영하고 있다.


역자 소개

Eva Study : Pattern과 소프트웨어 공학 지식을 외부에 알린다는 의미로 Eva (Evangelism) 라는 이름으로 10년이 넘게 꾸준히 활동하고 있다. 다양한 도메인의 맴버들이 모여, 90개가 넘는 무료 Webcast를 공유, 잡지 기고, 패턴 만들기등 왕성한 활동을 하고 있다. 또한 패턴의 진원지인 PLoP(패턴 학회)에 패턴을 발표한, 패턴 저자들의 모임이다.


고객의 요구사항보다 여러분의 이력에 더 우선순위를 두지 말라 Nitin Borwankar
본질적인 복잡성을 단순화시키고 예상치 못한 복잡성을 줄여라 Neal Ford 
가장 큰 문제는 기술이 아니다 Mark Ramm 
소통이 왕이라면, 명확성과 리더십은 그의 신하이다 Mark Richards 
애플리케이션 아키텍처는 애플리케이션 성능을 결정한다 Randy Stafford 
요구된 기능에서 가치 추구하기 Einar Landre 
일어서라 Udi Dahan
모든 것은 궁극적으로 실패하게 된다 Michael Nygard 
여러분은 생각보다 더 자주 협상한다 Michael Nygard 
정량화시켜라 Keith Braithwaite 
한 줄의 실행되는 코드가 500줄의 명세(스펙)만한 가치를 한다 Allison Randal 
한번에 딱 맞는 해결책은 없다 Randy Stafford
성능은 조기에 고려해야 한다 Rebecca Parsons 
아키텍팅이란 균형에 관한 것이다 Randy Stafford 
커밋하고 도망가는 것은 범죄다 Niclas Nilsson 
한 가지 이상의 방식이 존재할 수 있다 Keith Braithwaite
비즈니스 추진력 Dave Muirhead 
일반화 이전에 단순화, 재사용성 이전에 사용성`Kevlin Henney 
아키텍트는 직접 실무를 담당해야 한다 John Davies
지속적으로 통합하라 David Bartlett
일정을 지켜라 Norman Carnovale 
아키텍처적인 트레이드오프를 고려하라 Mark Richards 
요새 같은 데이터베이스를 구축하라 Dan Chak 
설계의 기준으로써 불확실성을 사용하라 Kevlin Henney 
주의 : 거울로 보이는 문제는 보이는 것보다 클 수 있다 Dave Quick 
재사용은 단지 아키텍처뿐 아니라 사람과 교육에 관한 것이다 Jeremy Meyer 
Architecture에 I는 없다 Dave Quick
1000피트의 뷰를 가져라 Erik Doernenburg 
결정하기 전에 시도하라 Erik Doernenburg 
비즈니스 도메인 이해하기 Mark Richards 
프로그래밍은 새로운 제품을 설계하는 행위와 같다 Einar Landre 
개발자에게 자율성을 부여하라 Philip Nelson 
시간은 모든 것을 바꾼다 Philip Nelson 
소프트웨어 아키텍트는 단지 소문자 a를 나타낸다. 소문자 a처럼 행동하라 Barry Hawkins 
범위는 성공의 적이다 Dave Quick 
쇼맨십을 넘는 가치 있는 청지기 정신 Barry Hawkins 
소프트웨어 아키텍처에도 윤리가 있다 Michael Nygard 
마천루는 확장할 수 없다 Michael Nygard 
이질성의 승리 Edward Garson 
모든 것은 성능에 관한 것이다 Craig Russell 
백지 위에 아키텍트 Michael Nygard 
정황이 왕이다 Edward Garson 
드워프, 엘프, 마법사, 그리고 왕 Evan Cofsky 
건축물을 짓는 건축가에게 배워라 Keith Braithwaite 
반복 작업과 싸워라 Niclas Nilsson 
현실 세계에 오신 것을 환영합니다`Gregor Hohpe 
제어하지 말아라. 대신 관찰하라 Gregor Hohpe 
야누스 아키텍트 David Bartlett 
아키텍트의 초점은 경계와 인터페이스에 있다 Einar Landre
개발자에게 권한을… Timothy High
결정에 대한 근거를 남겨라 Timothy High
가정에 도전하라. 특히 여러분이 세운 가정에! Timothy High 
경험과 지식을 공유하라 Paul W. Homer 
패턴 중독 Chad LaVigne 
아키텍처 메타포어를 확대 해석하지 말자 David Ing 
운영과 유지 보수에 집중하라 Mncedisi Kasper 
두 개를 선택할 마음의 준비를 하라 Bill de hora 
견해, 취향보다는 원리, 원칙, 유추를 먼저 고려하라 Michael Harmer 
걸어다니는 해골로 시작하라 Clint Shank 
데이터가 핵심이다 Paul W. Homer 
간단한 것은 간단하게 하라 Chad LaVigne 
설계하기 전에, 그것을 먼저 코드화할 수 있어야 한다 Mike Brown 
ROI 변수 George Malamidis 
여러분의 시스템이 레거시인 것을 고려해 설계하라 Dave Anderson 
단 하나의 솔루션만 있다면, 다른 의견을 구하라 Timothy High
변화의 충격을 이해하라 Doug Crawford 
하드웨어 역시 이해해야 한다 Kamal Wickramanayake 
손쉬운 방법은 훗날 이자가 붙어 되돌려 받게 된다 Scot Mcphee
완벽함은 충분함의 적이다 Greg Nyberg 
‘좋은 아이디어’를 피하라 Greg Nyberg 
훌륭한 콘텐츠는 훌륭한 시스템을 만든다 Zubin Wadia 
영업부서와 화가 난 아키텍트의 대결 구도 Chad LaVigne 
시스템을 검증하기 위해 범위를 늘려라 Stephen Jones 
구현 가능한 것만 설계해야 한다 Mike Brown 
장미를 장미라 부르지 않으면, 결국 양배추가 된다 Sam Gardiner 
문제가 안정적이어야 높은 품질의 솔루션을 얻을 수 있다 Sam Gardiner
근면성이 필요하다 Brian Hart 
자신의 결정에 책임감을 가져라 Yi Zhou 
영악하지 말자 Eben Hewitt 
주의깊게 무기를 선택하고, 신중하게 내려 놓아라 Chad LaVigne 
여러분의 고객은 여러분의 진정한 고객이 아니다 Eben Hewitt
보이는 것처럼 그렇게 되지 않는다 Peter Gillard-Moss
다른 프레임워크와 잘 어울리는 프레임워크를 선택하라 Eric Hawthorne 
탄탄한 비즈니스 사례를 만들어라 Yi Zhou 
코드뿐만 아니라 데이터도 제어하라 Chad LaVigne 
기술 채무를 갚아라 Burkhardt Hufnagel 
문제 해결사가 되지 말라 Eben Hewitt 
편리한 시스템을 구현하라 Keith Braithwaite
열정적인 문제 해결사들을 찾고 유지하라 Chad LaVigne 
소프트웨어는 실제로 존재하지 않는다 Chad LaVigne 
새로운 언어를 배워라 Burkhardt Hufnagel 
미래를 보장하는 솔루션을 만들 수는 없다 Richard Monson-Haefel 
사용자 수용성 문제 Norman Carnovale 
맑은 콩소메의 중요성 Eben Hewitt 
최종사용자에게는 인터페이스가 시스템이다 Vinayak Hegde 
훌륭한 소프트웨어는 만들어지는 것이 아니라 성장하는 것이다 Bill de hora 

한국의 아키텍트들
정경유착 김동열 
소통하는 아키텍처가 되자 김선형 
소프트웨어 아키텍트에게 필요한 세 가지 역량 류한석 
불나방과 프로젝트 박현철 
컨설팅 그리고 사과 손영수 
개발에 있어 형식에 얽매이는 행위야말로 삽질이다 신현묵 
‘공통’은 모든 사람들이 접근하는 광장이다 이충헌 
소프트웨어를 넘어 시스템으로, 아키텍처를 넘어 시스템으로 이해일