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

소프트웨어 아키텍트가 알아야 할 97가지
	원제
	지은이Richard Monson-Haefel
	옮긴이
	펴낸곳Eva Study
	쪽수367쪽
	ISBN9788993827330
	펴낸날2011년 04월 14일
	읽은날

재밌는 책이다. 업계의 고수들의 이야기를 듣는 것은 언제나 재밌다. 많은 고수들의 이야기가 재미있는 것은 곰곰히 뜯어보면 서로 반대되는 이야기가 있다는 점이다. 
이 책의 한 가지 흠이라면, 원서에 없는 국내 아키텍트 8인의 글이 들어 있다는 것이다. 원서가 전해주는 느낌과는 전혀 다른 느낌이다. 그래서 흠이다.

아키텍트는 참으로 외롭고 고단한 직업이다. 많은 것을 해야 하고, 할 줄 알아야 한다. 97가지나 알고 있다가는 심장마비가 걸리겠다. 느낀 점은 아키텍트는 대략 보수적이어야 한다. 그리고 정치가야 한다. 이 두 가지만 명심하자.

언제나 그렇지만, 자세한 것은 나중에. 그냥 목차만 즐기자.

고객의 요구사항보다 여러분의 이력에 더 우선순위를 두지 말라 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